部署可以简单到什么程度

部署可以简单到什么程度

去年我们组做了一个内部工单看板，前端用 React 构建，产出物是 dist/ 目录。部署流程只有两步：npm run build，然后 rsync -a --delete dist/ /srv/nginx/html/ticket-board/。没有容器，没有 systemd unit，没有任何需要维护的进程。CI 配置文件里这段脚本不超过十行，新人接手零学习成本。相比之下，同一时期另一个 Node 服务版本迭代时反复出现依赖版本冲突、端口占用、进程意外退出，光是修这些部署侧的问题就花掉两天。

故障面几乎为零

静态页没有运行时。这意味着不会 OOM，不会有事件循环阻塞，不会因某个 npm 包内存泄漏导致服务半夜挂掉。唯一可能出问题的环节是 Nginx 本身或者 CDN 节点，而这两者的稳定性远好于任何应用层代码。我们把三个内部工具迁移成纯静态部署后，相关告警量直接归零。运维侧不再需要为这些工具分配独立的监控、日志和重启策略，这本身就省下了大量维护工时。

跳过联调，开发迭代快得多

做内部工具最常见的痛点是：后端排期排不上。纯静态方案里，数据获取有两种务实做法。轻量场景直接把数据编译进产物——构建时从数据库或接口拉一份 JSON 塞进 window.__INITIAL_DATA__，页面刷新时重新拉；稍重一点的场景则直接调已有的只读 API，前端自己处理分页和缓存。无论哪种，都不需要后端专门为你写新接口。改完代码走一次 CI 就能上线，从提需求到可用通常在半天以内。

安全面收窄，但权限仍需要处理

纯静态页没有服务端执行逻辑，SQL 注入、命令注入、反序列化攻击这些传统服务端漏洞面完全消失。但内部工具依然需要权限控制——常见做法是把鉴权放在网关层，用 nginx auth_request 模块或者在 CDN 边缘函数里校验 JWT，静态资源路径本身不需要任何逻辑。如果工具涉及写操作（提交表单、修改状态），可以只把写接口做成极薄的云函数，读侧仍保持全静态。

什么情况下别硬撑

并非所有内部工具都适合纯静态。判断标准很简单：如果页面内容需要每次请求实时从数据库计算，或者存在复杂的权限模型和审计日志需求，那就老老实实写服务端。我见过有人硬用纯静态做了一套需要事务回滚的审批流程，最后不得不推翻重来。工具的数据量如果超过构建时间可接受的阈值（我们实测大约 5 万条记录会拖慢构建到不舒适），也应该考虑动态方案。