内部工具的用户数，撑不起一套应用架构

内部工具的用户数，撑不起一套应用架构

我们内部有个查订单状态的工具，日活 12 人，其中 8 个是客服。这种规模上 React + Node + Docker + K8s，运维成本远大于它创造的价值。改成纯静态页之后，产物就是一个 dist/ 目录，扔在 nginx 的 /tools/order/ 下，没有进程、没有端口、没有健康检查，机器重启也不影响它。

判断标准很简单：如果工具的核心逻辑是“把几个接口的数据拼起来给人看”，那它就该是静态页。

部署：一条 rsync，回滚也不慌

构建脚本就三行：npm run build、rsync -avz --delete dist/ tools@host:/srv/www/order/、刷一下 CDN 缓存。没有镜像、没有滚动发布、没有 latest 标签的歧义。

• 回滚 = 把上一次的 dist 再 rsync 一遍，压缩包留在 CI artifact 里，30 秒搞定；
• 灰度 = 复制一份到 /tools/order-next/，把链接发给两个人试用；
• 本地调试直接 npx serve dist，跑的就是线上产物，不存在“本地能跑线上不行”。

数据从哪来：静态壳 + 后端接口

静态不等于没有数据。页面加载后用 fetch('/api/orders?ids=...') 拿 JSON 渲染，接口由已有的业务服务提供，静态页只负责展示和交互。跨域就用同域反代，把 /api 转发到后端，省掉处理 CORS 和 cookie SameSite 的一堆麻烦。

对“每天看一眼”的报表类工具，更省事的做法是定时生成 JSON 快照：CI 每天 7 点跑一个脚本，把聚合结果写成 data/daily.json 提交到仓库，页面直接读静态文件。没有后端、没有连接池，数据延迟一小时在这种场景完全可接受。

登录和权限，交给网关

不要在静态页里自己写登录态。我们把工具挂在 tools.internal.example.com 下，前面挡一层 oauth2-proxy，未登录请求直接跳内网 SSO。页面能拿到的只有用户邮箱，通过 /api/me 读出来显示在右上角，用来做粗粒度隐藏，比如只有 SRE 才显示“重跑任务”按钮。

要记住：前端隐藏按钮不是权限控制。真正的校验必须在后端接口里做，静态页只是不让人误点。

三年后还能打开，才是好工具

静态页最被低估的优点是抗腐化。没有 node_modules、没有 lockfile 冲突、没有“Node 14 升不上去所以构建挂了”。我们把产物连同源码一起归档，最坏情况下双击 index.html 用 file:// 也能打开——前提是资源路径写成相对路径 ./assets/...，别写死 /assets/。

交接时给新人一个仓库，README 里写清构建命令和 rsync 目标，半小时能改一个字段。这比让他去理解一套三年前的微前端配置便宜太多。