从‘它怎么又挂了’到‘服务真稳’：我是如何用PM2守护我的Node.js生产环境的
从‘它怎么又挂了’到‘服务真稳’：我是如何用PM2守护我的Node.js生产环境的
记得第一次把Node.js项目部署到服务器时，我天真地以为node app.js就是全部。直到凌晨三点被报警短信吵醒，发现服务已经挂了6小时——用户投诉像雪花一样飞来。那一刻我才明白，生产环境不是游乐场。经过无数次崩溃、重启、排查的循环后，PM2成了我的救星。现在，我的服务已经稳定运行400多天，下面分享这套经过实战检验的PM2生存指南。
1. 为什么你的Node.js服务总在深夜崩溃
当我们在开发环境运行node app.js时，很少有人会思考：如果进程崩溃了怎么办？如果服务器重启了怎么办？如果内存泄漏了怎么办？生产环境像一头野兽，而裸奔的Node.js进程就像没穿盔甲的骑士。
典型翻车现场：
- 未捕获的异常导致整个进程退出
- 服务器重启后需要手动启动服务
- 日志文件膨胀到100GB撑爆磁盘
- 单核CPU无法应对突发流量
# 这是大多数人的起点（也是噩梦的开始） $ node app.js我曾用nohup、&甚至screen试图解决问题，直到发现PM2这个专为Node.js设计的进程守护神。它不仅能在崩溃后自动重启，还提供：
- 集群模式（充分利用多核CPU）
- 日志管理（自动分割、时间戳）
- 性能监控（内存/CPU实时查看）
- 启动脚本（系统重启自动恢复）
2. PM2核心生存技能包
2.1 安装与基础配置
全局安装PM2只需一行命令：
npm install pm2 -g启动你的应用（告别裸奔）：
pm2 start app.js --name "my-api"关键参数解析：
| 参数 | 作用示例 | 必要性 |
|---|---|---|
| --name | 给进程起个响亮的名字 | ★★★ |
| --watch | 代码变动自动重启 | ★★☆ |
| --max-memory | 限制内存用量（如300M） | ★★★ |
| --log | 指定日志路径 | ★★★ |
提示：生产环境一定要用
--max-memory，我曾经有个服务因为内存泄漏一夜之间吃掉了16GB内存。
2.2 集群模式：榨干你的CPU性能
Node.js单线程的特性意味着默认情况下，你的4核CPU有3个在睡大觉。启动集群模式：
pm2 start app.js -i max这个-i max会让PM2根据CPU核心数自动创建进程实例。在我的8核服务器上，吞吐量直接提升了6倍。
集群管理技巧：
- 用
pm2 scale my-api +2动态增加2个实例 pm2 reload all实现零停机重启（先启动新进程再关闭旧进程）- 配合Nginx的负载均衡效果更佳
2.3 日志管理：从混沌到秩序
默认情况下，PM2会把所有日志输出到~/.pm2/logs。如果不加管理，很快就会遇到：
- 单个日志文件过大（我曾经有个40GB的日志文件）
- 无法按日期检索历史日志
- 关键错误被淹没在海量输出中
解决方案是安装pm2-logrotate：
pm2 install pm2-logrotate推荐配置（添加到~/.pm2/module_conf.json）：
{ "pm2-logrotate": { "max_size": "100M", "retain": "30", "compress": true, "dateFormat": "YYYY-MM-DD_HH-mm-ss" } }这样会：
- 当日志超过100MB时自动分割
- 保留最近30个日志文件
- 启用gzip压缩节省空间
- 使用清晰的日期格式命名
3. 进阶生存指南
3.1 开机自启：应对服务器重启
经历过服务器宕机后手动恢复服务的人都知道，开机自启不是可选项。用这条命令生成启动脚本：
pm2 startup然后保存当前进程列表：
pm2 save现在即使服务器重启，你的服务也会自动恢复。我在AWS的spot实例上测试过，中断恢复完全无感知。
3.2 监控面板：上帝视角看服务
PM2自带的监控命令已经很强大了：
pm2 monit但如果你想要更炫酷的界面，可以试试：
pm2 plus这个云端监控服务可以：
- 跨多台服务器统一查看状态
- 设置智能告警（内存超过80%时通知）
- 查看历史性能数据
注意：虽然免费版够用，但对隐私敏感的项目建议使用自建方案。
3.3 环境变量与配置文件
生产环境一定要区分配置。我推荐使用ecosystem.config.js：
module.exports = { apps: [{ name: "prod-api", script: "app.js", instances: "max", env: { NODE_ENV: "production", PORT: 3000, DB_HOST: "prod-db.example.com" }, env_development: { NODE_ENV: "development", PORT: 3001, DB_HOST: "localhost" } }] }启动时指定环境：
pm2 start ecosystem.config.js --env production4. 我踩过的坑与填坑指南
4.1 内存泄漏排查
某次发版后，内存使用每小时增长2%。PM2的--max-memory-restart参数救了我：
pm2 start app.js --max-memory-restart 500M配合pm2 logs --lines 1000找到内存增长前的最后日志，最终定位到一个未关闭的数据库连接池。
4.2 零停机部署技巧
我的部署脚本现在长这样：
git pull npm install pm2 reload ecosystem.config.js --env production关键点：
reload比restart更优雅- 在低峰期执行
- 提前用
pm2 logs开个窗口观察
4.3 多项目共存管理
当服务器上运行着10多个Node.js服务时，我建立了这样的目录结构：
~/services/ ├── api-gateway/ │ ├── ecosystem.config.js │ └── ... ├── auth-service/ │ ├── ecosystem.config.js │ └── ... └── payment-service/ ├── ecosystem.config.js └── ...然后用统一的启动脚本：
#!/bin/bash services=("api-gateway" "auth-service" "payment-service") for service in "${services[@]}"; do cd ~/services/$service pm2 startOrReload ecosystem.config.js --env production done这套体系让我们的部署时间从1小时缩短到5分钟。