Node.js 的部署看起来简单——装好 Node 环境、git pull 代码、npm install、node index.js 就完事了。但在实际的持续运行环境中，有很多细节如果不注意，上线之后就会出现各种稳定性问题。这篇文章总结了我个人在几个 Node.js 项目上踩过的坑和最终的实践方案。
第一个话题是进程管理。直接运行 node index.js 的问题是当进程崩溃之后没有人去重启它。所以需要一个进程管理工具来自动守护你的 Node 进程。常用的有 PM2 和 systemd。如果你的服务器用的是 Linux 且服务数量不多，我建议优先考虑 systemd——它是操作系统自带的进程管理器，无需额外安装，并且支持开机自启、崩溃重启、日志收集、资源限制等一系列功能。在 /etc/systemd/system/ 下写一个简单的 service 文件，配置好 ExecStart、WorkingDirectory、Restart 这几个关键参数，然后用 systemctl enable 设置为开机启动就行了。PM2 的优势在于它有自己的进程列表管理界面和零停机重启功能，适合需要频繁更新和监控多个 Node 进程的场景。
环境变量管理是第二个容易被忽略的问题。API 密钥、数据库连接字符串、第三方服务的 Token，这些绝对不能硬编码在代码里，也不能随代码一起提交到 Git。推荐的做法是在 systemd service 文件中通过 Environment 或者 EnvironmentFile 来注入环境变量到进程的启动环境中。EnvironmentFile 更好一些，因为它把敏感信息和 service 文件的定义分开了，你可以给 EnvironmentFile 设置更严格的文件权限。
第三个问题是日志。Node 应用打印到 stdout 和 stderr 的日志，如果直接运行 node 不加任何重定向，这些日志就会打印在终端上，关闭终端之后就没了。用 systemd 管理的话，标准输出会被 journald 自动收集，你可以用 journalctl 来查看和搜索。用 PM2 的话它也有内置的日志管理功能。如果应用的日志量比较大，可以进一步接入集中化的日志系统（比如 ELK、Loki 或者阿里云的 SLS），但这对于小型个人项目来说通常用不到。
最后要提一下健康检查。你的负载均衡器或者监控系统需要知道你的 Node 应用当前是否健康。实现方式很简单——在应用中暴露一个 HTTP 端点（比如 /health），返回 200 状态码表示一切正常。更进阶的做法是让这个端点检查所有必要的依赖——数据库是否可连接、Redis 是否可访问等——如果任何一项检查失败就返回非 200 状态码。这样当你配合 Uptime Kuma 这类监控工具时，如果应用出了任何内部组件的问题都能第一时间收到告警。