PM2高可用必须依赖ecosystem.config.js配置文件，因pm2 start app.js仅启动单实例、无内存限制、无集群模式、未注册系统服务，无法实现崩溃自动恢复、开机自启和多核容错；关键三项是instances:'max'、exec_mode:'cluster'、max_memory_restart:'1G'，且必须先pm2 start ecosystem.config.js --env production、再pm2 save、最后pm2 startup，顺序错误将导致重启后进程丢失。
宝塔面板本身不直接管理Node.js进程的高可用，真正起作用的是它集成的PM2——只要配置对了ecosystem.config.js和系统级自启，应用就能在崩溃、重启、内存溢出时自动恢复，达到生产级高可用。
为什么pm2 start app.js不能直接用于生产？
这条命令只启动单个实例，没设内存限制、没开集群、没绑定环境变量、也没注册为系统服务。服务器一重启，进程就消失；代码抛个未捕获异常，服务就永久挂了。
-
pm2 start是开发调试用的快捷方式，不是生产部署方案 - 生产必须用配置文件（如
ecosystem.config.js），否则pm2 save和pm2 startup无法正确持久化状态 - 直接命令行启动的进程，
pm2 startup生成的systemd服务脚本会忽略它
必须写ecosystem.config.js的三个关键项
这个文件是PM2高可用的“宪法”，漏掉任意一项都可能让守护失效。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
-
instances: 'max'：让PM2根据CPU核心数拉起多个实例，单点崩溃不影响整体服务；若只写1，等于放弃多核容错能力 -
exec_mode: 'cluster'：配合instances启用集群模式，所有实例共享同一端口，由PM2内部负载分发；不设这个，多个实例会抢端口报EADDRINUSE -
max_memory_restart: '1G'：硬性内存红线，防止缓慢内存泄漏拖垮整台服务器；值太小（如512M）会导致频繁误重启，太大（如2G）又起不到保护作用
pm2 startup之后还要手动pm2 save吗？
要，而且顺序不能错。很多用户执行pm2 startup后以为万事大吉，结果重启后发现进程没起来——因为pm2 startup只是生成systemd服务脚本，它加载的是上次pm2 save保存的进程列表。
- 先用
pm2 start ecosystem.config.js --env production启动应用 - 确认
pm2 list里状态是online，再运行pm2 save - 最后执行
pm2 startup，它会输出类似sudo env PATH=$PATH:/www/server/nvm/versions/node/v18.16.0/bin /www/server/nvm/versions/node/v18.16.0/lib/node_modules/pm2/bin/pm2 startup systemd -u www --hp /www/wwwroot/my-app的命令，照着执行即可 - 验证：执行
sudo reboot后，等1分钟，再pm2 list看是否自动恢复
宝塔PM2管理器界面里哪些操作会破坏高可用？
宝塔的图形化界面方便，但也藏了几个“一键毁灭”按钮。
- 点击“重启”或“重载”按钮，会绕过
ecosystem.config.js，以默认参数重新拉起进程（比如回到单实例、无内存限制） - 在“设置”里修改“启动脚本”路径，会覆盖配置文件中
script字段，导致后续pm2 reload行为异常 - 勾选“开机自启”但没先做
pm2 save，等于给systemd喂了个空列表 - 真正安全的操作只有：在宝塔里上传/编辑
ecosystem.config.js，然后在SSH终端里执行pm2 reload ecosystem.config.js --env production
高可用不是靠多点几次按钮实现的，而是靠配置文件的确定性 + 启动流程的不可跳过性。最容易被忽略的是pm2 save这一步——它看起来像备份，其实是把当前运行态“刻录”进系统服务的唯一凭证。
