PM2集群模式需用-i max或-i 4显式启用，max为字符串；reload支持滚动重启但需监听SIGUSR2，restart则硬重启；内存泄漏排查需结合pm2 monit、日志及堆快照分析。
PM2启动时如何正确设置集群模式与CPU核心数
PM2默认以单实例运行，想利用多核必须显式启用集群模式。不设参数直接 pm2 start app.js 会跑成单进程，浪费资源且无法横向扩展。
正确做法是用 -i 参数指定实例数：pm2 start app.js -i max 让PM2自动匹配CPU核心数；也可写死为 -i 4。注意 max 是字符串，不是变量，别加引号或写成 "max"——那样会被当作文本路径处理，报 Script not found 错误。
集群模式下，PM2通过内置的负载均衡器分发HTTP请求（Round-Robin），但前提是你的应用监听的是同一端口（如 3000），且没手动调用 cluster.fork()——PM2自己管进程分发，你自己再fork会导致端口冲突或子进程失控。
何时该用 pm2 reload 而不是 pm2 restart
restart 是硬重启：杀掉所有工作进程，再拉起新实例，中间有毫秒级请求丢失；reload 是滚动重启：逐个替换进程，保持服务始终有至少一个实例在线。对生产环境的HTTP服务，优先选 reload。
但有两个前提条件必须满足：
- 应用代码里要监听
SIGUSR2信号并主动关闭当前事件循环（比如用server.close()），否则PM2发了信号，进程不响应，最终超时 fallback 成restart - 不能在
app.js开头就调用process.exit()或同步阻塞操作，否则新进程起不来，旧进程又等不到优雅退出，卡在“waiting for process to exit”状态
验证是否生效：改完代码后执行 pm2 reload app，然后看 pm2 show app 输出里的 status 列是否短暂出现 online → restarting → online，而不是直接跳变。
内存泄漏导致自动重启失败的排查线索
PM2的 --max-memory-restart 看似能兜底，但实际容易失效。比如设了 --max-memory-restart 512M，但Node进程RSS涨到600M时，PM2可能只杀掉worker，却不拉新进程——因为主进程还在，而它已因OOM被系统kill，只剩孤儿worker。
关键检查点：
- 用
pm2 monit观察memory曲线是否持续爬升，而非偶发尖峰 - 查
pm2 logs --raw是否有FATAL ERROR: Reached heap limit或系统级Killed process（这是Linux OOM Killer干的，PM2无权干预） - 确认
ecosystem.config.js中的watch: true没误开——文件监听+热重载在生产环境极易引发内存累积
临时缓解可用 --exp-backoff-restart-delay 100 避免频繁重启压垮机器，但根源还得用 node --inspect + Chrome DevTools 抓堆快照。
配置文件里 exec_mode 和 instances 的真实作用
很多人以为 exec_mode: 'cluster' 是开启集群的开关，其实它只是告诉PM2“我打算跑集群”，真正起效靠的是 instances 值。如果 instances: 1，哪怕写了 cluster，也只起一个进程。
ecosystem.config.js 示例中常见错误：
module.exports = {
apps: [{
name: 'api',
script: './server.js',
exec_mode: 'cluster',
instances: 'max', // ✅ 正确：字符串 max
// instances: max, // ❌ 语法错误，max未定义
// instances: '2', // ✅ 也可写数字字符串
}]
}
另外，exec_mode 只影响PM2自身调度逻辑，不影响你的代码是否用 cluster 模块——二者混用会冲突。PM2集群模式下，process.env.NODE_APP_INSTANCE 会自动注入实例序号，比自己读 cluster.worker.id 更可靠。
复杂点在于，某些数据库连接池（如 pg）默认按进程实例分配连接，集群下每个worker都建满连接，总连接数翻倍。这时候得在代码里根据 process.env.NODE_APP_INSTANCE 动态调小 max 参数，不然很快打满DB连接池。
