pm2 7.0.4 介绍与选型指南

pm2 7.0.4 介绍与选型指南：Node.js 生产进程管理器的定位、核心架构、功能特性、官方快速上手与 systemd/Supervisor/Docker 等同类方案选型对比，版本与社区数据于 2026-10-18 实查官方源

pm2pm2进程管理2026/10/18

pm2 7.0.4 介绍与选型指南

目标：说清 pm2 7.0.4 是什么、能解决什么问题、核心架构与功能特性如何支撑 Node.js 应用的生产托管，并给出与 systemd、Supervisor、Docker 等同类方案的选型对比建议。本文为认知篇，版本号、发布信息、社区数据与对比信息均于 2026-10-18 实查官方源（npm registry、GitHub Releases、官方文档站），本地安装与命令实测见《Ubuntu 22.04 安装 pm2 7.0.4 指南》《pm2 7.0.4 常用 CLI 命令与工具详解》《pm2 7.0.4 配置参数详解》三篇。

一、环境信息

本章说明本文全部论断的信息基准：查询日期、版本依据与官方来源清单，便于读者复核版本与数据的时效性。

💡 说明：pm2 7.x 是当前大版本线，npm registry 上 7.x 系列已发布 7.0.0～7.0.4 共 5 个版本（2026-10-18 实查）。生产环境建议直接使用 latest 标签对应的 7.0.4，本文全部内容以 7.0.4 为准。

二、软件概述

pm2（Process Manager 2）是一个面向 Node.js 应用的生产级进程管理器，官方描述为 "Production process manager for Node.JS applications with a built-in load balancer"（npm registry 实查，2026-10-18）。它解决的核心问题是：Node.js 单进程一旦崩溃或随终端退出就停止服务，而生产环境需要进程「崩溃自动拉起、随服务器开机自启、多核并行利用、日志统一收集、不停机升级」这一整套托管能力。

pm2 由 Unitech 公司（Keymetrics 团队）维护，采用 AGPL-3.0 许可证开源，同时提供商业化的 pm2 Plus / pm2.io 监控面板作为可选增值服务。开源部分完全自足，不连接外部服务也可正常使用全部核心功能。

几个关键事实（均于 2026-10-18 实查）：

项目值来源
最新稳定版7.0.4（npm latest 标签）npm registry
发布时间2026-08-24GitHub Releases v7.0.4
许可证AGPL-3.0npm registry license 字段
Node.js 要求>= 18.0.0npm registry engines 字段
维护方Unitech（Keymetrics）GitHub 仓库 Unitech/pm2
社区热度stars 43312 / open issues 1110GitHub API

关键差异解读：pm2 与普通「包管理器/构建工具」不同，它是一个常驻守护层——安装后自身会以一个守护进程（God Daemon）的形式常驻系统，所有被托管的应用进程都由它统一派生、监控与回收。理解这一点是理解后续架构与选型的前提。

三、核心架构

pm2 的运行形态是「一个守护进程 + 一组被托管的应用进程 + 一个 CLI 客户端」的三层结构。本章按从进程关系到磁盘目录的顺序拆解。

3.1 守护进程（God Daemon）与 CLI 客户端

执行任意 pm2 命令时，CLI 客户端会先检查本机是否已有 pm2 守护进程；没有则自动拉起一个常驻的 God Daemon（实测进程名形如 PM2 v7.0.4: God Daemon，工作目录 /root/.pm2），随后通过 RPC 接口与守护进程通信完成启动、停止、查询等操作。这意味着：

  • 被托管的应用进程是守护进程的子进程，与终端会话（SSH 断开）完全解耦，天然后台化；
  • CLI 命令是「薄客户端」，本身不持有应用进程，只负责把指令转达给守护进程；
  • 守护进程崩溃时应用进程会失去父进程管理，因此 pm2 与 systemd 集成（见 3.3）来守护「守护进程本身」。

3.2 两种执行模式：fork 与 cluster

同一个应用脚本，pm2 支持两种执行模式（官方文档 Applications Declaration / cluster-mode 章节），这是 pm2 最核心的架构分叉点。

💡 技术拓展：Node.js 应用在 pm2 中的执行模式不止「单进程 fork」一种，两类模式对比如下——

模式原理实例数端口复用适用场景
fork_mode以子进程方式直接执行脚本，各实例独立进程1（默认）不能，多实例需各自监听不同端口普通 worker 脚本、非 HTTP 服务、单实例 Web 应用
cluster_mode基于 Node.js 官方 cluster 模块，主进程绑定端口后分发给 worker可 1～N（-i 指定，max 取 CPU 核数）能，多实例共享监听同一端口HTTP/HTTPS/WebSocket 网络服务、多核利用

pm2 官方推荐网络类服务一律使用 cluster 模式：端口由主进程统一绑定，内置负载均衡把连接分发给各 worker，且 pm2 reload 可逐个替换 worker 实现零停机升级。本文后续篇章的实测（B1/D1/C1）对 HTTP 服务均采用 cluster 模式。

cluster 模式内置的负载均衡采用操作系统级的轮询分发（Node.js cluster 模块的默认调度策略，Linux 下为 round-robin 接受连接），无需额外组件即可把请求摊到多个 worker 上。一般业务场景轮询已足够均匀；若需要会话保持或按权重分发，应在 pm2 之前加 Nginx/HAProxy 一类专业负载均衡器，而不是依赖 pm2。

3.3 开机自启与 systemd 集成

pm2 自身是守护进程，服务器重启后需要有人拉起它。pm2 通过 pm2 startup + pm2 save 两个命令与系统 init 集成：pm2 startup 生成并注册系统服务（Ubuntu 22.04 上是 systemd 单元 pm2-<user>.service，如 root 用户为 pm2-root.service），单元的 ExecStart 指向 pm2 resurrect；pm2 save 把当前进程列表序列化到 ~/.pm2/dump.pm2，开机时由 resurrect 按清单恢复全部应用。也就是说「开机自启」的实际链条是：systemd 拉起 pm2-root.service → 执行 pm2 resurrect → 读取 dump.pm2 → 逐个恢复应用进程。

💡 技术拓展：pm2 startup 会自动探测系统的 init 服务体系并生成对应的服务脚本，常见 init 体系对比——

init 体系代表系统pm2 生成的服务形态
systemdUbuntu 16.04+ / Debian 8+ / RHEL 7+pm2-<user>.service 单元文件
UpstartUbuntu 14.04 等旧版init 脚本
launchdmacOSLaunchAgent plist
OpenRCGentoo / Alpinerc 脚本

Ubuntu 22.04 固定使用 systemd，pm2 startup 会自动识别为 systemd（实测回显 [PM2] Init System found: systemd），无需手动指定平台。

3.4 磁盘目录布局（~/.pm2）

pm2 的一切状态都落在当前用户的 ~/.pm2 目录下（root 用户为 /root/.pm2），主要包括：

路径作用
~/.pm2/dump.pm2pm2 save 写入的进程清单，开机 resurrect 的依据
~/.pm2/pm2.logpm2 守护进程自身的日志（含内存超限重启等事件）
~/.pm2/logs/<app>-out.log应用 stdout 日志（cluster 模式按实例编号分文件）
~/.pm2/logs/<app>-error.log应用 stderr 日志
~/.pm2/pids/<app>-<id>.pid应用进程 PID 文件
~/.pm2/pm2.pidpm2 守护进程自身的 PID 文件

关键差异解读：日志默认在 ~/.pm2/logs/ 下按应用分文件；当应用以 cluster 模式多实例运行时，除非在配置中开启 merge_logs，否则每个实例各写一份带实例编号的日志（如 web-out-0.log、web-out-1.log）。生产环境通常通过配置文件把日志重定向到统一目录（如 /var/log/<app>/），详见《pm2 7.0.4 配置参数详解》。

四、功能特性

本章按「日常使用频率从高到低」梳理 pm2 7.0.4 的主要功能域，各功能的命令级实测与参数细节见《pm2 7.0.4 常用 CLI 命令与工具详解》与《pm2 7.0.4 配置参数详解》。

4.1 进程守护与自动重启

应用进程异常退出（崩溃、OOM 被杀）后由守护进程自动拉起，默认无限次重启；可通过 --max-restarts、--restart-delay、--exp-backoff-restart-delay、--stop-exit-codes 控制重启策略。另一类守护是内存守护：--max-memory-restart 设定内存阈值，超限后自动重启进程，事件会记录到 pm2 守护进程日志。两者结合可覆盖「崩了拉起」与「泄漏自愈」两类最常见的生产诉求。

4.2 零停机 reload 与 cluster 负载均衡

对 cluster 模式的网络服务，pm2 reload <app> 逐个重启 worker：先起新 worker、再退旧 worker，始终保留存活实例承接连接，实测中 reload 全程 HTTP 服务不中断。配合 -i N 多实例，可以在单机上吃满多核并具备实例级容错。fork 模式的单实例应用没有这层保护，reload 等价于 restart，会有短暂中断。

4.3 日志管理

pm2 统一收集所有应用的 stdout/stderr：pm2 logs 实时流式查看（支持按应用过滤、--lines 指定回看行数、--time 带时间戳），pm2 flush 清空日志，pm2 logrotate 安装 logrotate 配置实现按天轮转切割。日志路径与合并行为可在配置文件中逐应用定制。

4.4 监控与指标

pm2 list/status 展示进程表（CPU、内存、重启次数、uptime）；pm2 monit / pm2 dashboard 提供终端交互式监控界面（实时 CPU/内存曲线与日志）；pm2 describe <app> 输出单应用全量元数据与运行指标（堆大小、事件循环延迟、HTTP 延迟分位数等，由内嵌 pmx 探针采集）；pm2 jlist 以 JSON 输出全量进程数据，供脚本与外部监控系统消费。连接 pm2 Plus（pm2.io）可获得 Web 控制台与告警，属商业增值服务，非必需。

4.5 开机自启

pm2 startup（生成并启用系统服务）+ pm2 save（固化进程清单）两步完成，见 3.3。对应卸载命令为 pm2 unstartup。

4.6 配置文件（ecosystem）

应用启动参数可整体落盘为 ecosystem.config.js：应用名、脚本路径、执行模式、实例数、内存阈值、日志路径、多环境变量组（env / env_production）集中声明，pm2 start ecosystem.config.js --env production 一条命令按环境拉起整套应用。官方同时支持 .yaml/.json 形态，JavaScript 形态最常用。

4.7 模块系统与编程 API

pm2 自带模块系统（pm2 install <module>），可安装如 pm2-logrotate（日志轮转）、pm2-server-monit（服务器监控）等官方模块，模块本身也以受托管进程形式运行。此外 pm2 提供编程 API（require('pm2')，官方文档 Programmatic API 章节），可在 Node.js 程序内通过 pm2.connect() / pm2.start() 等函数直接管理进程，用于构建自有控制台或自动化脚本。

五、快速上手

以下最小流程引自官方文档站 Quick Start（https://pm2.keymetrics.io/docs/usage/quick-start/）与 GitHub README（https://github.com/Unitech/pm2），本文原样列出供建立整体认知；逐条命令的真实安装与运行实测见[《Ubuntu 22.04 安装 pm2 7.0.4 指南》](https://www.quzuo.net/document/Jr2rvxY9ypR9)。

# 安装 pm2（全局，需已具备 Node.js >= 18 环境）
npm install -g pm2

# 启动应用（守护化，自动重启）
pm2 start app.js

# 查看进程列表
pm2 ls

# 实时监控 CPU/内存
pm2 monit

# 查看应用日志
pm2 logs

# 配置开机自启（生成系统服务并启用）
pm2 startup

# 固化当前进程清单，供开机恢复
pm2 save

💡 说明：以上为官方文档原样示例。其中 pm2 start app.js 会把 app.js 交给 pm2 守护进程以 fork 模式运行；HTTP 服务建议改用 pm2 start app.js -i max 以 cluster 模式吃满多核（官方 README 示例同样给出 pm2 start api.js -i 4 的多实例形态）。各命令的完整参数与实测回显见《pm2 7.0.4 常用 CLI 命令与工具详解》。

六、适用场景与限制

6.1 适用场景

  • Node.js Web 服务生产托管：单机多核利用（cluster + 负载均衡）、崩溃自愈、零停机发布，是 pm2 最典型的主场；
  • 常驻 worker / 定时任务进程：消息消费、数据同步、轮询脚本等需要「挂了就拉起」的后台进程；
  • 多应用单机聚合管理：一台服务器上跑多个 Node 应用/服务时，用 pm2 统一列表、日志与开机自启，替代散落的 nohup/screen；
  • 无容器化基础设施的传统机房：不依赖 Kubernetes 等平台，直接在系统层获得进程守护能力。

6.2 限制与注意

  • 许可证为 AGPL-3.0（npm registry 实查，2026-10-18）：对 pm2 本体的修改与网络服务化使用需遵守 AGPL 义务；仅以未修改形态通过 npm 安装使用、不修改分发其源码的常规运维场景一般不触发额外义务，商用前建议由法务确认；
  • 不做资源隔离：pm2 管进程但不做 CPU/内存限额与隔离，多应用互相挤占资源需依靠 cgroup/容器层或应用自身限流；
  • 单机边界：pm2 的进程列表、负载均衡、reload 都是单机的，跨机器部署与编排需自行配合 Nginx 上游或交由 Kubernetes 等平台；
  • 守护进程自身依赖托管：pm2 God Daemon 若被误杀，其子进程管理随之失效，务必按 3.3 完成 systemd 集成，让 init 体系来守护 pm2 本身；
  • Windows 平台：pm2 可在 Windows 运行但官方生态与自启支持以 Linux/macOS 为主，生产建议 Linux。

七、同类选型对比

进程托管这一需求在业界有多类实现，本章横向对比 pm2 与常见替代方案，数据与能力描述均于 2026-10-18 对照各官方文档实查（来源见文末参考链接）。

7.1 对比总表

方案定位与实现守护与自启多实例/负载均衡零停机升级应用级监控适用场景
pm2 7.0.4Node.js 生态进程管理器（Node.js 实现）内置守护 + pm2 startup 对接 systemd原生 cluster 多实例 + 内置轮询负载均衡pm2 reload 原生支持（cluster 模式）进程表/堆/事件循环/HTTP 延迟等应用指标Node.js 应用的单机生产托管首选
systemdLinux 系统 init 与服务管理器（C 实现）系统级最强，Restart= 策略原生无应用级多实例，需模板单元（@.service）自建无原生支持，需 socket activation 或自写脚本只有进程级资源统计，无应用指标非 Node 专属的通用服务托管、系统底座
Supervisor通用进程管理器（Python 实现）自带 supervisord 守护 + 自启配置无内置负载均衡，多实例=多 program无原生支持，需配合脚本进程状态与资源，无应用级指标非 Node 的多语言混合进程托管
Docker（restart 策略）容器运行时（Go 实现）守护进程层面 --restart 拉起容器无内置应用级负载均衡（需 Compose 多副本+外置 LB）滚动更新需 Compose/Swarm/K8s 编排层容器级资源统计已容器化交付的应用
nodemon开发期文件监听重启工具（Node.js 实现）无守护、无自启，随终端存活无无无仅本地开发热重载，不适合生产

7.2 选型建议

  • Node.js 应用、单机或少量机器：选 pm2。cluster 多实例、零停机 reload、应用级指标、ecosystem 配置化都是 Node 专属开箱能力，systemd/Supervisor 需要大量自建脚本才能逼近；
  • 混合语言进程、纯系统层托管：选 systemd（系统自带、最稳）或 Supervisor（配置直观、生态成熟），把 pm2 仅用于其中的 Node 部分；
  • 已全面容器化/上 Kubernetes：进程守护交由容器平台（restart 策略、Deployment 滚动更新），pm2 在容器内通常退化为单进程前台运行（pm2-runtime 形态），不再承担集群编排职责；
  • 开发环境热重载：nodemon/node --watch 即可，不要用 pm2 承担开发期职责。

💡 说明：pm2 与 systemd 并不互斥，官方推荐形态恰是「systemd 守护 pm2 本体 + pm2 守护应用进程」的双层结构（见 3.3），这也是《Ubuntu 22.04 安装 pm2 7.0.4 指南》中 systemd 托管一章的标准做法。

八、参考链接