在 Linux 服务器上部署 Node.js 应用时，真正麻烦的往往不是“怎么启动”，而是“怎么稳定地一直跑下去”。如果只是执行一次 node app.js，终端关闭、SSH 断开，进程很可能就跟着结束了。

这篇文章按使用场景把几种常见方案拆开讲：先看适合临时任务的 nohup，再看便于保留会话的 screen/tmux，最后对比生产环境更常见的 PM2 和 systemd。看完你可以更快判断，当前项目到底该选“先跑起来”，还是直接上正式托管方案。

为什么 Node.js 进程管理很重要

在开发机上，直接运行 node app.js 通常没问题；但在 Linux 服务器上，这种方式很难满足长期运行的要求。只要终端会话结束，或者 SSH 连接中断，进程就可能退出。

因此，进程管理方案至少要解决下面几个问题：

• 终端断开后，应用能否继续运行；
• 应用崩溃后，能否自动重启；
• 是否方便查看日志和运行状态；
• 系统重启后，能否自动恢复服务。

不同工具解决问题的深度不同，适用场景也不一样。

临时任务：用 nohup 让进程在后台继续运行

如果你只是临时跑一个脚本、做一次测试，nohup 是最直接的办法。它的核心作用是让进程忽略挂断信号（SIGHUP），即使终端退出，进程也不会跟着结束。

nohup node app.js > output.log 2>&1 &

这条命令里有几个关键点：

• nohup：让进程忽略终端挂断；
• > output.log 2>&1：把标准输出和错误输出都写入 output.log；
• &：把进程放到后台执行。

它的优点是简单、几乎所有 Linux 环境都能直接用；但缺点也很明显：没有进程监控，没有自动重启，进程异常退出后不会有人接手。所以它更适合临时场景，不适合长期托管生产服务。

需要保留会话：用 screen 或 tmux

如果你希望应用在后台运行的同时，还能随时回到原来的终端查看输出，screen 和 tmux 会更合适。它们本质上是终端复用器，可以创建独立会话，你断开连接后会话依然存在，之后还能重新接入。

以 screen 为例，常见操作流程如下：

• 安装：sudo apt-get install screen
• 创建并命名会话：screen -S my_node_session
• 在会话中启动应用：node app.js
• 分离会话：按 Ctrl-A，再按 D
• 重新连接会话：screen -r my_node_session

这种方式比 nohup 更灵活，因为你可以直接看到实时输出，也方便继续交互式操作。它尤其适合调试、手动运维，或者需要临时保留运行上下文的任务。

但要注意，screen 和 tmux 的重点是“保留会话”，不是“托管进程”。如果 Node.js 进程自己崩溃了，它们并不会自动拉起应用。

大多数 Node.js 项目：优先考虑 PM2

如果你要的是一个真正面向 Node.js 的进程管理方案，PM2 通常是最省心的选择。它不仅能把应用放到后台运行，还提供自动重启、日志管理、状态查看，甚至负载均衡等能力。

先全局安装 PM2：

npm install pm2 -g

启动应用：

pm2 start app.js

日常管理时，常用命令包括：

• pm2 list：查看所有进程状态
• pm2 stop app.js：停止应用
• pm2 restart app.js：重启应用
• pm2 logs：查看日志
• pm2 startup：生成开机自启配置

PM2 的价值在于，它把 Node.js 应用运行中最常见的需求都打包好了：崩溃自动重启、统一查看状态、日志集中管理，以及更适合线上部署的运维体验。对于大多数 Node.js 项目来说，PM2 已经足够覆盖日常生产需求。

要和系统服务体系集成：使用 systemd

如果你的目标不是单纯“把 Node.js 跑起来”，而是把它当成一项正式系统服务来管理，那么 systemd 是更标准的做法。这样一来，Node.js 应用就能像 Nginx、MySQL 一样，统一纳入 Linux 的服务管理体系。

首先创建服务文件：

sudo nano /etc/systemd/system/nodeapp.service

然后写入下面内容，注意将路径和用户名替换为实际值：

[Unit]
Description=Node.js Application Service
After=network.target

[Service]
Type=simple
User=
WorkingDirectory=/path/to/your/node/app
ExecStart=/usr/bin/node /path/to/your/node/app/app.js
Restart=on-failure

[Install]
WantedBy=multi-user.target

保存后，可以使用下面几条命令完成基础管理：

• sudo systemctl start nodeapp：启动服务
• sudo systemctl enable nodeapp：设置开机自启
• sudo systemctl status nodeapp：查看服务状态和最近日志

systemd 的优势在于，它与 Linux 系统原生集成度最高。日志可以交给 journalctl，服务依赖、重启策略、资源限制也都能通过 .service 文件统一配置。对于追求标准化部署、统一运维和长期维护的环境，这通常是更正式的一条路。

怎么选：按场景判断就够了

如果只是临时执行脚本或短期测试，nohup 足够简单，成本最低。

如果你需要保留交互式会话，并在断线后继续查看输出，screen 或 tmux 更合适。

如果是常规 Node.js 项目，希望有自动重启、日志和状态管理，PM2 往往是最均衡的方案。

如果你要把应用纳入系统服务体系，和其他 Linux 服务统一管理，那么 systemd 会更规范。

从生产环境角度看，PM2 和 systemd 通常更值得优先考虑：前者更贴近 Node.js 开发者的使用习惯，后者更符合 Linux 运维体系。具体选哪一个，取决于你更看重“Node.js 友好型管理”，还是“系统级标准化托管”。