评大师 · 技术架构

技术架构评估需要可观測的运行痕迹。评大师最直观的技术信号来自错误页：404 页面返回的是「404: This page could not be found」加「## This page could not be found.」的 Markdown 风格文案，这正是 Next.js 默认 404 模板的典型特征。结合登录页与注册页同为 React 生态的渲染表现，可高置信度推断其前端技术栈为 Next.js（或相近的 React 框架）。Next.js 支持 SSR/SSG，但评大师在门禁场景下显然未对公开页启用预渲染，否则登录页至少应吐出语义化 HTML 供爬虫与首屏使用。这一取舍说明团队更重视数据安全而非公开可达性，是技术服务于商业门禁策略的体现。

资源托管方面，站点将 logo（/assets/default/gms_logo.svg）、微信二维码（/assets/default/qrcode.png）、客服图标（/service.svg）等静态资源置于独立路径，说明存在规范的前端构建流水线，资源经过打包、目录归类后统一分发，通常背后有对象存储 + CDN 支撑，首屏图标加载应具备基本性能保障。这种「动静分离」的工程习惯，是成熟 SaaS 项目的标配，评大师在此处没有明显短板，资源路径命名也较为规整（default 目录暗示多主题/多商户资源隔离的可能），侧面反映其前端工程具备一定的标准化程度。

安全与数据层面，登录页集成手机号验证码、独立子账号体系、服务协议与隐私协议勾选，暗示后端具备短信网关、账号权限模型与合规文档系统。但门禁架构本身也带来一个隐性技术优势：所有业务数据都在鉴权之后，外部无法直接探测 API 或爬取用户内容，攻击面被天然收窄。不过，缺乏公开的 robots.txt 与 sitemap.xml（均被门禁）也说明站点没有为爬虫做任何服务端适配，属于「主动放弃公开索引」的技术取舍，与 seo 维度的弱势互为因果，体现了工程资源向「保护数据」而非「开放索引」倾斜。

扩展性维度，子账号体系的存在表明其数据模型已支持多租户/多用户组织，具备向团队、企业版演进的底层结构。若后端采用微服务或至少模块化设计，评大师在功能堆叠上不会有架构瓶颈。但所有这些判断都建立在「门外可见痕迹 + 行业常识」之上，真实的数据库选型、缓存策略、限流与监控体系均不可知，因此 tech_architecture 评分定为中上而非更高，留出了对内部质量的未知空间。总体而言，其前端工程水准可信，架构延展性合理，但内部深度不可证，不宜过度高估。

一个值得指出的技术权衡是：SPA + 全站门禁虽然保护了数据，却牺牲了公开可观测性，使得外部无法用常规手段（如 Lighthouse、安全扫描）评估其性能与安全水位。这在早期可接受，但当评大师需要接入企业客户做安全审计时，缺乏公开的技术透明度可能成为 To B 大客户准入的障碍。建议评大师在保持门禁的同时，对外提供基础的技术合规说明（如数据加密、等保、合规认证），以弥补「不可观测」带来的信任折扣，这也是其技术架构从「能用」走向「可信」的关键一步。从长期技术债角度，评大师当前「全站 SPA + 门禁」的架构在用户量突破一定规模、需要对接企业客户安全审计时，可能面临「透明度不足」的信任成本。建议在架构层面预留公开内容域（独立的 marketing/landing 子站或预渲染页），与门禁应用域解耦，既不影响数据安全，又能支撑 SEO 与品牌展示。这种前后端分离的「双域架构」是成熟 B2B SaaS 的惯用做法，值得评大师在中长期路线中考虑。此外，随着子账号与多租户规模扩大，权限模型的复杂度和数据隔离的健壮性将成为架构健康的晴雨表，需要在可观测性（日志、监控、审计）上提前投入，避免规模化后的运维黑盒。

（以下为基于 B2B SaaS 技术架构行业认知的推断）SPA 全站门禁在保护数据上合理，却牺牲了公开可观测性，使外部无法用 Lighthouse、安全扫描等常规手段评估其性能与安全水位，这在早期可接受，但当其需要接入企业客户做安全审计时，缺乏公开技术透明度可能成为 To B 大客户准入的障碍。成熟做法是在保持门禁的同时，对外提供基础技术合规说明（数据加密、等保、合规认证），并预留独立的公开内容域（marketing/landing 子站或预渲染页）与门禁应用域解耦——既不影响数据安全，又能支撑 SEO 与品牌展示，这是成熟 B2B SaaS 的惯用「双域架构」。随着子账号与多租户规模扩大，权限模型的复杂度与数据隔离的健壮性将成为架构健康的晴雨表，需要在日志、监控、审计等可观测性上提前投入，避免规模化后的运维黑盒。从扩展性看，子账号体系的存在表明数据模型已支持多租户/多用户组织，向团队与企业版演进无架构瓶颈；但真实的缓存策略、限流与监控体系不可知，tech_architecture 评分定中上，留出了对内部质量的未知空间，不宜过度高估其工程深度。（以下为基于SaaS工程行业认知的推断）从工程投入产出比看，评大师当前把资源明显倾斜到了「数据安全与门禁」一侧，而对「公开可观测性」投入不足，这在初创期是合理的取舍；但当其客群向企业级迁移时，安全审计、等保合规、数据加密说明等公开技术透明度将成为准入门槛。建议在架构层面预留独立的公开内容域，与门禁应用域解耦，既不影响数据安全，又能支撑SEO与品牌展示，这是成熟B2B SaaS的惯用双域架构，也直接回应了前面多个维度提到的公开内容缺失问题。