云主机部署Node服务时，进程守护的核心答案是：优先使用PM2进行进程管理，复杂服务或需系统级集成时改用systemd，两者都能实现崩溃自动重启和开机自启。
云主机部署node服务怎么进程守护？先搞懂这3个坑
很多新手把Node服务扔到云主机上，用node app.js跑起来就以为完事了，结果过几天发现服务挂了，或者SSH一断开服务就没了,其实问题就出在没做进程守护。
第一个坑是进程闪退，Node服务代码里一个未捕获的异常，或者内存踩爆，进程直接退出，没有任何自动重启机制，第二个坑是终端绑定，你直接在终端里跑服务，关掉SSH窗口，服务跟着一起死，第三个坑是云主机重启后服务不恢复，比如酷番云、简米云的服务器日常维护重启，你没有配置开机自启,就得手动连上去重新拉起来。
行业共识认为，进程守护的核心就两件事：崩溃时自动拉起，开机时自动运行，做不到这两点,服务就不算真正部署完成。
用PM2守护Node进程：最简单也最稳妥
PM2是Node生态里最常用的进程守护工具，内置负载均衡、日志管理、内存监控，而且命令行操作非常顺手，对于绝大多数云主机部署Node服务的场景,PM2足够用了。
PM2安装和启动命令
先用npm全局安装：
npm install -g pm2
然后启动服务，注意要带--name给进程起个名字,方便后面管理：
pm2 start app.js --name my-node-app
启动后可以看状态：
pm2 status
你会看到进程的pid、运行时间、内存占用，以及restarts次数，如果程序崩溃，PM2会自动重启，restarts数字就会增加。
让PM2开机自启（含酷番云、简米云场景）
PM2本身不直接管开机启动，需要生成一个系统服务,执行两条命令：
pm2 save pm2 startup
pm2 save保存当前进程列表，pm2 startup会输出一条带sudo的指令，复制执行即可，这样云主机重启后,PM2会作为系统服务自动把所有保存的进程拉起来。
注意一点：如果你用的是酷番云或简米云的轻量应用服务器，系统镜像可能是Ubuntu或CentOS，PM2的startup命令能自动识别init系统，执行完建议手动重启一次云主机验证,确认服务真的自动恢复了。
PM2内存监控和自动重启
Node服务最怕内存泄漏，PM2可以设置内存上限,超了自动重启：
pm2 start app.js --max-memory-restart 300M
或者对已运行的进程设置：
pm2 restart my-node-app --max-memory-restart 300M
这样当进程内存占用超过300MB，PM2会先尝试触发gc，如果还在涨就直接重启，配合pm2 monit可以实时查看CPU和内存曲线,排查问题方便很多。
systemd和PM2对比：什么场景该用哪个？
PM2虽然好用，但有些场景下systemd更合适，比如你需要严格控制系统启动顺序，或者想让Node服务和其他系统服务（如Nginx、数据库）一起由systemd统一管理,那直接用systemd写unit文件更干净。
下面用表格直观对比两者的差异：
| 对比项 | PM2 | systemd |
|---|---|---|
| 安装难度 | npm一键安装 | 云主机自带 |
| 配置复杂度 | 命令行为主，简单易懂 | 需要写unit文件，语法有门槛 |
| 日志管理 | 自带日志轮转、实时查看 | 配合journalctl，需要配置 |
| 开机自启 | 需要额外执行startup | 配置文件里写enable即可 |
| 多进程管理 | 自带cluster模式 | 需要自己控制多个unit |
| 系统集成度 | 独立运行，依赖Node | 系统级，和网络、依赖强相关 |
如果你只是跑一两个Node服务，选PM2，如果服务要接入系统网络（比如需要
After=network-online.target）或者和系统安全策略联动,用systemd。
systemd守护Node服务的配置写法
在/etc/systemd/system/下新建一个my-node.service文件：
[Unit] Description=My Node Service After=network.target [Service] Type=simple User=root WorkingDirectory=/var/www/myapp ExecStart=/usr/bin/node /var/www/myapp/app.js Restart=always RestartSec=3 Environment=NODE_ENV=production [Install] WantedBy=multi-user.target
关键参数是Restart=always，表示无论什么原因退出都自动重启，配合RestartSec=3防止频繁重启,然后执行：
systemctl daemon-reload systemctl start my-node systemctl enable my-node
enable就是开机自启，查日志用journalctl -u my-node -f，比PM2的日志稍显朴素,但胜在系统级统一。
服务崩溃自动重启：进程守护的核心逻辑
不管用PM2还是systemd，你要理解重启策略怎么设置才合理，不是所有崩溃都要立刻重启，比如代码里存在明显bug导致启动后秒退，这时无限重启会疯狂刷日志,占满磁盘。
PM2默认情况下，如果进程在启动后几秒内反复退出，它会停止重启并标记为errored，你可以通过--min-uptime和--max-restarts控制：
pm2 start app.js --min-uptime 5000 --max-restarts 3
意思是进程至少稳定运行5秒才算正常启动，如果连续3次启动后又在5秒内崩溃，就不继续重启了，systemd里也有StartLimitIntervalSec和StartLimitBurst参数,默认配置多数情况下够用。
测试守护是否生效的方式很简单：找到node进程的pid，执行kill -9 该pid，模拟强制崩溃，然后看PM2或systemd是否在几秒内自动拉起进程,这是我每次部署后必做的验证步骤。
云主机进程守护收费吗？成本真相
很多用户担心进程守护会不会额外收费，明确说，
PM2和systemd本身完全免费，不产生任何额外费用，但要注意，云主机上跑服务,真正花钱的是主机本身的价格。
比如你买一台酷番云或简米云的轻量服务器，一年可能几百块，进程守护只是系统自带的功能，不会单独列一项费用，如果你用云厂商的托管服务，比如Serverless或者容器服务，那按调用次数或实例运行时长计费,但这和传统云主机上的进程守护不是一回事。
所以结论是：自己管理云主机，用PM2或systemd做进程守护，不存在额外收费，云主机的价格主要看配置、带宽和地域,和进程守护方式无关。
云主机部署Node服务常见问题
问：PM2和systemd哪个更适合新手？
PM2更适合新手，它的命令行简洁，日志清晰，还有网页版监控面板pm2 plus（虽然部分功能收费），systemd的unit文件语法需要学一阵，但一份配置写好后可以复制到其他主机，如果你刚接触云主机，先用PM2跑通,再慢慢看systemd。
问：Node服务内存泄漏导致自动重启频繁，怎么排查？
先用pm2 monit看哪个进程内存持续增长，再结合日志定位泄漏点，常见原因包括全局变量缓存、数据库连接未释放、事件监听器未移除，重启只是治标，根本解法是修代码，可以设置--max-memory-restart触发重启,给排查争取时间。
问：云主机重启后服务没自动拉起，可能是什么原因？
PM2没执行pm2 save和pm2 startup，或者执行后没有用sudo运行生成的命令，systemd则需要确认systemctl enable成功，另外检查服务文件里WorkingDirectory路径是否正确，很多情况下是工作目录不存在导致启动失败，重启前先手动执行一下服务命令,确认能正常启动再谈开机自启。
进程守护不是锦上添花，是云主机部署Node服务的基本功，无论你选PM2还是systemd，核心就是让服务在崩溃时自己爬起来，云主机重启后不用人管，先把守护配好,再谈业务上线。