使用 PM2 守护 Node.js 进程及生产环境部署优化

在 Linux 云服务器上直接运行 node app.js 部署 Web 服务时，一旦 SSH 终端连接断开，前台进程往往随之被终止；即使用 nohup node app.js & 放到后台，当运行时出现未捕获的未处理异常（Unhandled Exception）时，进程依然会崩溃退出并导致服务完全中断。面对这种单点脆弱性，PM2（Process Manager 2）提供了一整套专为 Node.js 生产环境设计的进程生命周期托管方案，涵盖后台常驻守护、崩溃自动重启、多核负载均衡与零停机平滑更新。

一、为什么生产环境必须使用进程管理器

Node.js 原生采用单线程事件循环架构。这一特性使其在处理高并发 I/O 时极为高效，但也带来了天然的运行缺陷：单个工作进程只能利用单颗 CPU 核心的计算算力，且任意一个阻塞或未捕获的运行时错误，都会直接导致整颗进程退出。若没有上层调度者实时监控进程状态，业务便会长时间陷入不可访问的瘫痪状态。

PM2 的核心角色是一个独立于应用业务逻辑的后台 Daemon 守护进程。它持有业务子进程的 PID 控制权，负责监听进程的 exit 信号、监控资源消耗上限，并根据预设的重启策略进行瞬时拉起。此外，PM2 通过内置的 Node.js cluster 集群模块驱动，让单体应用无需修改业务代码即可横向扩展为多进程多核架构，并在新版本发布时实现完全不中断流量的优雅重载。

二、PM2 基础安装与核心管理命令

在生产服务器上，推荐通过 npm 全局安装 PM2，以保证管理命令在任何路径下均可直接执行。建议确认已安装的 Node.js 具备 LTS 长期支持版本（如 Node.js 18 或 20）。

# 1. 全局安装 PM2
npm install -g pm2

# 2. 验证安装版本
pm2 -v

在不使用配置文件时，可以通过简单命令直接拉起脚本：

# 以指定进程名称启动服务
pm2 start server.js --name "my-api"

# 查看当前运行中的所有进程列表与实时状态
pm2 list

# 查看实时聚合日志（支持通过进程名过滤）
pm2 logs my-api

# 查看仪表盘监控指标（实时查看 CPU 与内存占用）
pm2 monit

以下为日常进程操作指令与对应的执行效果：

三、基于 ecosystem.config.js 的规范化声明式配置

虽然通过命令行参数传递如 -i max 等标志位可以启动进程，但在严谨的生产流水线中，命令行启动极易因参数漏填或环境差异导致配置漂移。PM2 支持通过 ecosystem.config.js 文件进行声明式配置，将进程参数、多核集群策略、日志输出路径及环境变量统一纳入 Git 仓库进行版本控制。

在项目根目录下执行 pm2 ecosystem 可初始化该文件。生产环境推荐的标准配置示例如下：

module.exports = {
  apps: [
    {
      name: 'production-api',            // 进程在 PM2 中的统一注册名称
      script: './dist/main.js',          // 实际入口文件路径
      instances: 'max',                  // 'max' 代表根据 CPU 物理核心数自动分配实例
      exec_mode: 'cluster',              // 生产环境必须指定 cluster 模式以启用多核负载均衡
      
      // 环境变量管理
      env: {
        NODE_ENV: 'development',
        PORT: 3000
      },
      env_production: {
        NODE_ENV: 'production',
        PORT: 8080
      },

      // 异常保护与内存边界
      max_memory_restart: '500M',        // 实例占用超过 500MB 时触发平滑重置，防止内存泄漏打崩系统
      autorestart: true,                 // 进程异常退出时自动拉起
      restart_delay: 3000,               // 异常崩溃后的重启冷却时间（毫秒），避免死循环消耗算力
      max_restarts: 10,                  // 单位时间内连续异常的最大重试次数

      // 日志输出与格式配置
      output: './logs/out.log',           // 标准输出 (stdout) 目标路径
      error: './logs/err.log',            // 标准错误 (stderr) 目标路径
      log_date_format: 'YYYY-MM-DD HH:mm:ss Z', // 日志行前缀时间格式
      merge_logs: true,                  // 集群模式下将多个 worker 的日志合并写入同名文件

      // 平滑重载安全钩子
      wait_ready: true,                  // 等待应用触发 process.send('ready') 再切流量
      listen_timeout: 8000,              // 启动超时阈值（毫秒）
      kill_timeout: 5000                 // 退出超时阈值，超时则强制发送 SIGKILL
    }
  ]
};

准备好该配置后，启动与发布只需一条清晰的命令：

# 以生产环境环境变量启动 ecosystem 配置
pm2 start ecosystem.config.js --env production

四、Cluster 集群模式与无缝平滑重载（Zero-Downtime Reload）

默认情况下，PM2 以 fork 模式运行，这意味着你的程序仅作为一个独立的子进程运行。若要在多核服务器上榨干硬件算力，需要开启 cluster 模式。PM2 依赖 Node.js 的 cluster 模块，底层的 Master 进程共享同一个对外监听端口（如 8080），并在内核或内部采用轮询（Round-Robin）调度算法将网络连接分发到各个空闲的 Worker 子进程。

1. restart 与 reload 的本质区别

许多刚接触 PM2 的开发者在更新上线时习惯执行 pm2 restart all，这会在生产环境造成不可忽视的服务中断：

• pm2 restart：立即强行关闭所有运行中的旧实例，然后再逐一拉起新实例。在旧实例已死、新实例尚未完成数据库连接与端口监听的真空期内，所有进来的 HTTP 请求都将收到 502 Bad Gateway 或连接被拒绝。
• pm2 reload：采用滚动重载（Rolling Restart）策略。PM2 先启动一个新的 Worker 实例；等到新实例确认完全具备接收请求的能力后，再将流量平滑切入，并向旧实例发送优雅终止信号，等待旧实例把当前尚未返回的连接处理完毕后才予以清理。

2. 配合 wait_ready 实现真正的无缝切换

为了防止新 Worker 刚生成操作系统进程、但其框架路由和数据库池尚未初始化完成时就被分配流量，应用代码中应当显式通知 PM2 自身就绪状态：

// server.js 业务入口代码
const express = require('express');
const app = express();

app.get('/api/health', (req, res) => res.json({ status: 'ok' }));

const server = app.listen(process.env.PORT || 8080, () => {
  console.log(`Server listening on port ${process.env.PORT || 8080}`);
  
  // 显式告知 PM2 守护进程：当前 Worker 已准备好承接流量
  if (process.send) {
    process.send('ready');
  }
});

// 处理优雅退出逻辑
process.on('SIGINT', () => {
  console.log('收到 SIGINT 信号，开始关闭 HTTP 服务...');
  server.close(() => {
    console.log('所有在途请求处理完毕，进程安全退出');
    process.exit(0);
  });
});

五、服务器开机自启与状态持久化

单纯在终端中启动 PM2 并不意味着它能在服务器因机房断电、内核升级或宕机重启后自动恢复。必须借助 Linux 系统的初始化管理体系（如 systemd）实现开机持久化托管。

配置持久化守护只需执行两个标准步骤：

# 步骤 1: 根据宿主机初始化系统生成并注册自启脚本
pm2 startup

# 执行后终端会提示形如以下的命令（复制并执行该命令，通常需要 sudo 权限）：
# sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2-startup install systemd -u <当前用户名> --hp <主目录路径>

# 步骤 2: 将当前内存中正在运行的进程列表与状态冻结保存到磁盘
pm2 save

六、生产环境进阶优化与稳定性保障

在长期高负载运行的生产环境中，仅保证服务不退是不够的，还必须对内存溢出、日志爆盘与监控盲区进行系统性优化。

1. 内存泄漏熔断（max_memory_restart）

虽然 Node.js V8 引擎内置了垃圾回收（GC），但在高频闭包、大对象缓存或未释放的事件监听器影响下，依然容易发生渐进式内存泄漏。若不加限制，进程内存无限膨胀会导致操作系统触发 OOM Killer 直接杀掉关键进程。通过配置 max_memory_restart: '500M'，当某个 Worker 实例内存超过 500MB 时，PM2 会在不影响其他实例的前提下，自动对其执行平滑重启并回收物理内存。

2. 日志自动轮转（pm2-logrotate）

如果任由标准输出与错误输出持续追加写入，out.log 和 err.log 可能会在数月内膨胀到数十甚至数百吉字节（GB），最终导致云服务器磁盘空间耗尽并引发内核级只读锁死。PM2 提供了官方模块 pm2-logrotate 实现全自动日志切割：

# 安装官方日志轮转插件
pm2 install pm2-logrotate

# 配置单文件最大体积达到 20MB 时自动切割
pm2 set pm2-logrotate:max_size 20M

# 保留最近 14 个历史归档文件（更早的自动清理）
pm2 set pm2-logrotate:retain 14

# 开启 Gzip 压缩以节约磁盘存储空间
pm2 set pm2-logrotate:compress true

# 每天凌晨 0 点强制进行一次日志归档（Cron 表达式）
pm2 set pm2-logrotate:rotateInterval '0 0 * * *'

七、生产部署常见问题与排查清单

在实际生产落地中，以下 4 个场景是排查频次最高的故障诱因，需在上线前建立对应的检查项：

1. 集群模式下内存状态无法共享

当应用从 fork 切换到 cluster 多实例模式后，每一个 Worker 均持有完全独立的 V8 内存堆栈。若应用中使用了内存对象（如 const cache = {} 或本地 Session 变量），不同用户请求落到不同 Worker 上会导致数据不一致。解决方式：在生产架构中，将登录态 Session、高频缓存数据与定时任务状态抽离至独立的 Redis 或数据库中，使 Node.js 实例保持完全无状态（Stateless）。

2. 端口冲突报错 EADDRINUSE

如果在 fork 模式下启动了多个试图监听同一端口的实例，或者启动 PM2 前已有残存的 Node.js 进程占用了该端口，应用会立即报错 Error: listen EADDRINUSE :::8080。排查方式：执行 lsof -i :8080 或 netstat -tlpn | grep 8080 找到占用进程的 PID 并终止，确保该端口完全由 PM2 统一管理。

3. 部署后应用持续循环重启（Error Loop）

若通过 pm2 list 发现某个应用的 Restart 计数在几十秒内急剧上升至数十次，说明应用在启动入口处就发生了致命异常（如生产环境变量缺失、数据库连不上或静态构建产物路径错误）。排查方式：执行 pm2 logs <name> --lines 100 --err 直接拉取最新 100 行错误日志，定位未捕获的报错根因，而非盲目重启。

4. 定时任务在 Cluster 模式下被重复执行

如果业务代码中嵌入了 node-cron 或 setInterval，在启动了 4 个 Worker 的集群模式下，同一时刻定时任务会被并发执行 4 次。解决方式：通过判断 PM2 注入的环境变量 process.env.NODE_APP_INSTANCE === '0'，限定仅由 0 号主实例执行定时任务，其余 Worker 仅负责对外处理网络请求。

八、总结

使用 PM2 守护 Node.js 生产环境进程的核心路径可以归纳为规范的三个阶段：

1. 声明式规范化：使用 ecosystem.config.js 管理启动参数，将实例数指定为多核 cluster 模式，设定日志格式并配置 max_memory_restart 防御内存膨胀。
2. 系统层兜底：通过 pm2 startup 生成宿主机 systemd 系统服务，配合 pm2 save 固化进程状态，杜绝物理机重启造成服务丢失。
3. 零停机交付：通过业务端暴露 ready 握手信号配合 pm2 reload 进行代码更新，实现高并发业务在生产发布时的持续稳定运行。