静态站部署前，先量清楚服务器的内存账

给个人站写部署方案时，我犯了一个很典型的错误：先写约束，后量数据。

第一版方案

我写下这么一条需求：

单次构建的常驻内存 MUST NOT 超过 1536MB，以适应 2 核 2GB 且已运行其他生产容器的宿主。

看起来挺合理。实际上它算不过来。

量完之后

登上服务器实测：

$ free -m
               total        used        free      shared  buff/cache   available
Mem:           1888         909          77          72         901         750
Swap:             0           0           0

三件事同时暴露：

1. 内存不是 2GB，是 1888MB
2. Swap 是 0 —— 没有交换分区，内存冲顶就是直接 OOM kill
3. cgroup 没有限制，构建进程和 Harbor 的 9 个容器共享同一个内存池

最后一条最要命：构建峰值一旦失控，被杀的不只是构建进程，可能还有旁边跑着的容器。而“不触发 OOM killer”这句话，根本不是一个软件需求能保证的事情——它由宿主上所有进程共同决定。

改成了什么

把不可控的表述换成可测的：

• 构建整体移出服务器，交给 CI
• 服务器上不装 Node、不构建，只做拉取和原子切换
• 若将来必须在宿主构建，则用 cgroup 硬隔离，并实测峰值写入文档，而不是写一个估算值

教训

不是“应该更保守”，而是不该在没量之前写数字。1536 这个数字看起来精确，实际上是我拍的——精确的错误比模糊的正确危险得多，因为它让人以为已经想清楚了。

先量，再写。量不出来的，就别写成 MUST。