在 CentOS 上部署 Node.js 应用时，很多人先碰到的不是代码问题，而是“关掉终端后进程还在不在”。这类场景里，nohup适合快速把应用放到后台持续运行；如果还需要开机自启、状态检查和自动拉起，就要进一步考虑 rc.local 或 systemd。下面按实际使用顺序整理一遍，帮助你判断什么时候用简单命令，什么时候该切到服务管理。
用 nohup 在后台启动 Node.js 应用
先进入项目目录。假设应用位于 /home/user/my-node-app，可以先执行：
cd /home/user/my-node-app然后使用 nohup 启动 Node.js 主程序，并把标准输出和错误输出都写入日志文件：
nohup /usr/bin/node app.js > output.log 2>&1 &这条命令里有三个关键点：
> output.log：把标准输出写入output.log；2>&1：把错误输出合并到同一个日志文件；&：让进程转入后台运行。
这样做的好处是直接、成本低，适合临时部署、测试环境或手动维护的服务。只要终端关闭，进程也不会因为会话结束而退出。
如何查看运行输出和排查问题
应用启动后，第一件事通常不是“它有没有跑起来”，而是“它到底输出了什么”。既然已经把日志写到了 output.log，就可以直接实时查看：
tail -f output.log这个命令适合观察启动日志、端口监听信息和报错堆栈。对于用 nohup 跑起来的进程来说，日志文件基本就是最直接的排障入口。
如果应用只是偶尔手动启动，保留这种日志重定向方式已经够用；但只要进入长期运行阶段，单靠 nohup 往往还不够，因为它不负责开机自启、统一管理和异常重启策略。
需要开机自启时：rc.local 的简单做法
如果需求只是“服务器重启后自动把应用再拉起来”，可以把启动命令写进 /etc/rc.local。
先编辑文件：
sudo vi /etc/rc.local然后在 exit 0 之前加入一行启动命令：
nohup /usr/bin/node /path/to/your/app.js > /path/to/output.log 2>&1 &保存退出后，系统每次启动时都会执行这段命令，Node.js 应用也会随之启动。
这种方式优点是上手快，缺点也很明显：配置分散、状态不直观，后续维护时不如专门的服务管理方案清晰。它更适合轻量场景，不太适合需要长期稳定运行的生产服务。
更推荐的方案：交给 systemd 管理
如果希望应用像系统服务一样被管理，systemd 是更稳妥的选择。它不仅能开机自启，还能统一定义工作目录、运行用户和重启策略。
先创建服务单元文件，例如：
sudo vi /etc/systemd/system/my-node-app.service写入以下内容，并按实际环境修改路径和用户：
[Unit]
Description=My Node.js Application
[Service]
ExecStart=/usr/bin/node /path/to/your/app.js
WorkingDirectory=/path/to/your/app-directory
User=myuser
Restart=always
[Install]
WantedBy=multi-user.target这个配置里比较关键的几项分别是：
ExecStart：指定 Node.js 可执行文件和入口脚本；WorkingDirectory：指定应用运行目录；User：指定以哪个用户身份运行；Restart=always：进程退出后自动重启。
保存之后，执行启用和启动：
sudo systemctl enable my-node-app.service
sudo systemctl start my-node-app.service再用下面的命令检查服务状态：
sudo systemctl status my-node-app.service相比单独使用 nohup，systemd 更适合生产环境，原因在于它把启动、停止、重启、开机自启和服务状态都纳入了统一入口，后续维护成本更低。
怎么选：临时后台运行还是正式服务管理
如果你只是想快速把一个 Node.js 应用挂到后台运行，nohup /usr/bin/node app.js > output.log 2>&1 & 已经足够，部署成本最低，排查时直接看 output.log 即可。
如果你还需要开机自启，可以把命令写进 /etc/rc.local，但这更像简单补充方案。对于长期运行、需要稳定维护的服务，systemd 仍然是更推荐的做法，尤其是在需要状态检查和自动重启时，它会比单纯依赖 nohup 更省事。
