PM2 进程管理速查表 - Node.js 进程管理命令大全

现象机器重启后进程全没了，pm2 list 是空的。

原因pm2 startup 只是打印一段需要执行的命令，没有以对应用户实际跑过那行，自启单元就没被安装；pm2 save 保存的列表也需要它才能被读回。

处置先 pm2 save 保存当前列表，再执行 pm2 startup 输出的那行命令，之后可用 pm2 resurrect 验证恢复是否成功。

现象配置改了生效的却是旧值，重启多少次都一样。

原因进程仍按启动时的参数在跑，配置文件里新加的键从未被读入；也可能是启动时带了 --env 读的是另一段配置。

处置用 pm2 describe api 核对实际的启动命令与启动环境，确认后用 pm2 start ecosystem.config.js --env production 重新按配置拉起。

现象进程跑了一段时间后自己重启，重启计数一路往上涨。

原因内存超过 max_memory_restart 设的上限，PM2 按配置把它重启了；这是兜底生效，不是进程自己崩的。

处置用 pm2 show api 看重启次数与内存占用确认这一判断，再排查代码里的累积对象；短期可用 pm2 reset api 清零计数以免干扰观察。

现象本地明明在监听，服务却间歇性不通。

原因以 -i 开多实例后每个实例都试图绑定同一端口，先起来的占住端口，后起来的因冲突进入反复重启，列表里仍显示进程存在。

处置确认进程数与端口的关系，需要多实例时改用 cluster 模式（配置里的 exec_mode: "cluster"）并核对 pm2 list 中的实例数。

现象磁盘被日志占满，服务异常退出。

原因默认日志文件无限增长，没有轮转也没有清理，磁盘满之后进程写日志失败随之异常。

处置先 pm2 flush 清空现有日志腾出空间，再 pm2 install pm2-logrotate 安装轮转模块；需要固定位置时在配置里写清 error_file 与 out_file。

现象保存的进程列表恢复出来的是旧代码位置。

原因pm2 save 记录的是当时的启动命令与工作目录，之后代码换了目录或版本，resurrect 仍按旧记录拉起。

处置恢复后用 pm2 list 核对路径，确认不符就用 pm2 delete api 移除旧条目，再从当前配置重新启动。

现象自动重启的频率高得离谱，进程根本起不来。

原因watch 监听范围包含依赖与日志目录，运行时写日志或写缓存本身就触发文件变化，于是形成「启动-写文件-再重启」的循环。

处置在配置里保留 watch: true 并显式写 ignore_watch: ["node_modules", "logs"]，让触发点只落在真正改动的源码上。

现象终端里 pm2 面板刚打开就退出，什么也没看到。

原因实时面板靠刷新屏幕持续绘制，在非交互环境或输出被重定向时无法正常渲染。

处置改用一次性输出核对状态：pm2 list 看整体，pm2 show api 看单个进程的内存与重启次数。

现象重启次数被历史失败污染，看不出本次部署是否稳定。

原因重启计数在进程生命周期内一直累加，早期那次崩溃也留在里面，读数分不清是历史问题还是当前问题。

处置部署完成后用 pm2 reset api 清零计数，再观察 pm2 monit 的走势判断当前是否还在增长。