先想清楚：内部工具的用户是个位数到几十人

先想清楚：内部工具的用户是个位数到几十人

内部工具的真实画像通常是：使用者 5 到 50 人，峰值 QPS 个位数，没人会为它做容量规划，但每个人都会在周五下午提需求。这种场景下，迭代速度远比架构弹性重要。我们做过一个批量改商品标签的运营页面，从提需求到上线用了两个小时：一个 index.html 加一个 app.js，调两个已有的内部接口。如果走常规的后端服务，光是建仓库、配 CI、申请发布窗口就不止两天。

静态页的另一个隐性收益是没有运行时。没有进程、没有连接池、没有内存泄漏，也就没有半夜的告警电话。

部署链可以短到只剩一次上传

用 vite build 产出 dist/，直接推到对象存储的静态托管（OSS、COS、S3 都行），或者干脆放在内网 Nginx 的一个 location 里。关键是缓存策略要一次配对：

• index.html 设 Cache-Control: no-cache，保证每次拿到最新入口；
• assets/[name]-[hash].js 设一年强缓存，文件名带 hash 天然防串版本。

回滚就是把上一个版本目录的软链指回去，十秒钟的事，不需要数据库迁移，也不需要担心"旧版本还在跑"。整个工具没有状态，删掉重传不会有任何残留。

认证交给网关，别在前端造轮子

这是最容易走弯路的地方。很多人一上来就在前端写登录框、存 token、做角色判断，最后变成一个半吊子的权限系统。正确做法是把认证前移：Nginx 用 auth_request 把每个请求转发给公司 SSO 的校验接口，或者直接套 Cloudflare Access、阿里云 SLS 这类现成网关。前端只需要调一个 /api/me 拿到用户名和角色，用来决定菜单显示哪些项。

必须强调的是：前端隐藏按钮不是权限控制。所有写操作必须在服务端接口层再校验一次角色，静态页只负责"不让用户困惑"，不负责"不让用户作恶"。

数据从现成接口来，前端只做视图层

绝大多数内部工具需要的数据，后端团队已经有了接口，只是没人做过界面。静态页正好补这个缺口：fetch('/api/orders?status=3')，把 CORS 白名单加上内网域名，一行配置的事。

• 把筛选条件写进 URL query，比如 ?status=3&page=2，用户可以直接把链接贴到群里让别人复现同一个视图；
• 表单草稿存 localStorage，刷新和误关页面都不丢；
• 列表超过 500 行就上虚拟滚动或强制分页，别指望浏览器扛住一万个 DOM 节点。

什么时候别硬上静态页

静态页不是万能药，踩过边界就知道该收手：需要跨表事务的写操作、需要定时任务、需要 WebSocket 长连接推送、需要处理大文件上传和转码——这些都应该老老实实写后端服务。字段级的复杂权限矩阵同理，前端算不明白，也不该由前端算。

判断标准其实很简单：如果这个工具的核心价值是"把已有接口包装成人类能用的界面"，静态页就是最优解；如果核心价值在服务端的状态流转和计算，那前端用什么技术都只是附属品。