先确认现象#

先看 free -h、dmesg 和构建日志。如果出现 OOM killer 记录，就不是代码语法问题，而是资源问题。

我会保留一条修复前命令，证明问题确实存在。这样修复后才能对比，而不是凭感觉判断。

排查命令#

1
free -h
2
swapon --show
3
dmesg -T | grep -i 'killed process\|out of memory' | tail -n 20
4
NODE_OPTIONS=--max-old-space-size=1536 pnpm build

处理原则#

• 涉及服务器时，先备份配置或确认回滚方式。
• 涉及进程时，先判断它是不是线上服务。
• 涉及删除时，先用 du、ls、日志确认对象。
• 修完后必须做业务层验证，不只看报错消失。

复盘记录#

复盘时要记录 Node 版本、构建命令、内存峰值和是否使用 swap。不要长期依赖 swap 掩盖内存不足，但它可以让小服务器完成构建。

最小验收样例#

我会记录修复前后的两条命令输出。比如端口问题就保存监听状态，权限问题就保存文件权限，服务问题就保存状态和日志。没有对比证据，就很难说明问题确实被解决。

如果操作发生在服务器上，还要写明当前用户、工作目录和影响范围。排查文章不是命令收藏夹，而是下一次可以照着走的现场记录。

小结#

构建时内存不足怎么判断 不是记一个命令，而是记一条排查链路。现象、命令、输出、验证都留下，下次才不用重新猜。