如果你跟我一样写接口的时候觉得 Node.js 是全世界最好用的语言部署的时候又恨不得把电脑从窗户扔出去那这篇文章就是写给你的。Node.js 香在哪不用我多说——异步 IO 一个 Event Loop 打天下npm 生态要啥有啥前后端还能共用一套语言。但每次部署环境、依赖、进程、端口、代理这些问题就像约好了一样集体发作一次比一次让人血压高。这篇我不聊框架选型不聊性能调优就只聊部署这件事本身为什么会翻车、怎么排查、我现在怎么干。全文基于我部署过几十个 Node 项目的实际操作该给的命令和配置都会给到位。1. 真香是共识砸电脑也是共识部署为什么成了分水岭1.1 开发五分钟部署两小时香与痛的根源Node.js 为什么香开发体验太好了。代码写完npm start直接跑热重载一开保存即生效。没有编译步骤没有环境配置依赖缺失就npm install一下几秒钟搞定。但注意这种香是建立在开发机上的——你的电脑上已经装好了某个版本的 NodePATH里有一堆全局工具.env文件藏在项目目录里node_modules已经装得满满当当。这些东西凑在一起才让你觉得写起来真顺。但服务器是一张白纸。你要把一个在开发机上跑得欢快的 Node 项目搬到服务器上等于把一整套隐形环境全部重建一遍。Node 版本、npm 版本、依赖的编译工具链、端口占用、进程守护、反向代理、环境变量、日志目录……任何一环对不上应用就起不来或者半夜死掉。所以那句话怎么说来着本地跑通只证明你能跑服务器上跑通才叫部署完成。1.2 部署的本质把在我机器上能跑变成在任何地方都能跑我后来想明白一件事部署这件事本质上是把你开发时的个人环境翻译成一套可复现的公共环境。个人环境可以随意——Node 版本乱了就换依赖冲突了就删全局装了什么工具只有你自己知道。但公共环境必须确定因为你不是唯一维护这套系统的人而且服务器上没有你的肌肉记忆。从这个角度理解Node.js 部署痛并不怪 Node 本身而是大部分项目从来没人认真做过环境固化。如果你能用一套清单回答这三个问题——用哪个 Node 版本、装哪些依赖、怎么拉起进程——部署就成功了一半。这篇文章后边所有的方案都是在帮你把这三个问题变成固定的答案而不是每次部署时重新猜一遍。2. 部署现场最容易翻车的四个环节环境、依赖、进程、代理2.1 环境不一致我本机明明能跑这句话大概是部署事故里最经典的一句台词。你在本地开发时用的 Node 可能是 18甚至电脑上有四五个版本来回切换服务器上装的是系统源里的 Node 12。一跑起来ESM 语法报错、??操作符不识别、某些 API 不存在——你以为代码有问题其实是版本不对。解决办法其实很简单在项目根目录加一个.nvmrc文件里面写死 Node 版本号比如18.20.2。开发机上用 nvm 的人nvm use一下自动切版本服务器上部署脚本先执行nvm install读这个文件。另一个靠谱做法是把engines字段写进package.json并在.npmrc里设置engine-stricttrue这样依赖安装阶段就会强制检查版本版本不匹配直接报错而不是等启动时才炸。注意engine-stricttrue这个配置很容易被忽略但它的价值是让版本不匹配这个错误发生在最早期——装依赖时就报而不是跑起来才报。错误越早暴露排查成本越低。2.2 依赖装不对node_modules 成了玄学依赖问题比环境问题更隐蔽。最常见的是代码里用到了某个包但没写进package.json或者开发机上的node_modules里有旧版本代码在本地依赖了旧版本的行为上了服务器npm install装了新版本行为变了。还有一个经典翻车只提交了package.json没提交package-lock.json服务器上解析出来的依赖树跟本地完全不一样。正确的做法是package-lock.json必须提交进代码仓库服务器上安装依赖用npm ci而不是npm install。npm ci会严格按照 lock 文件安装速度比npm install快而且装完不会改 lock 文件。另外部署时记得区分生产和开发依赖——如果只是跑业务代码用NODE_ENVproduction npm ci --omitdev可以少装很多 devDependencies既省时间又省磁盘。2.3 进程没人管nohup 不是万能钥匙新手部署 Node 最常见的姿势是nohup node app.js 或者终端挂一个后台任务。当时确实能跑但问题是进程没人守护。Node 进程本身是单线程的一旦有未捕获的异常把进程带崩或者服务器重启你的服务就永远消失了直到有人发现网站打不开。这不是 Bug这是机制——Node 不会自动重启。所以进程守护必须交给专门工具。我最早用的是 PM2pm2 start app.js一行命令拉起进程pm2 save保存当前进程列表pm2 startup生成开机自启脚本配合--max-memory-restart做内存超限自动重启。后来上容器化之后进程守护这种事就交给容器的重启策略了。但不管用哪个方案原则是一样的你的 Node 进程必须有一个监护人能拉起、能守护、能重启。2.4 反向代理配置出错一切正常但你访问不了很多项目代码跑起来了日志也正常输出但浏览器一访问就 502。问题多半出在反向代理上。常见场景Node 服务监听在3000端口Nginx 把80端口转发过去但proxy_pass写错了路径或者http://127.0.0.1:3000;末尾多/少了一个斜杠行为完全不一样——带斜杠会替换匹配前缀不带斜杠则保留完整路径。这一类问题不看文档靠猜是猜不出来的。我的经验是代理配置写完先nginx -t测一下语法然后curl -I http://127.0.0.1:3000直连 Node 服务确认后端活着最后再curl -I http://服务器IP走代理链路。每一步分开验证出问题就知道卡在哪一段——是 Nginx 没起来、反代指向错了、还是 Node 服务本身没监听成功一步一个结论根本不用瞎猜。3. 我现在用的部署方案分场景给结论3.1 个人项目和小团队PM2 Nginx 完全够用先说结论如果你的项目是个人作品、小团队内部工具、或者访问量不太大的业务系统根本不需要一上来就上容器编排PM2 Nginx 这套组合最省心。具体步骤# 1. 安装 Node推荐用版本管理器或直接系统包管理装也行 # 2. 上传代码到服务器安装生产依赖 cd /var/www/myapp NODE_ENVproduction npm ci --omitdev # 3. 用 PM2 启动应用 pm2 start app.js --name myapp --max-memory-restart 512M pm2 save pm2 startupPM2 启动完之后pm2 status能看到进程状态和重启次数pm2 logs看实时日志。如果应用有多个实例需求可以用 cluster 模式pm2 start app.js -i maxPM2 会按 CPU 核数拉起多个进程共享同一个端口利用多核的同时还能做到滚动重启——一个实例挂了另外几个还在请求不会全部中断。然后是 Nginx 反代配置一个最小的 server block 长这样server { listen 80; server_name your-domain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }Upgrade和Connection这两个 header 不是可选项——如果你的应用用了 WebSocket比如实时推送、在线协作少了这两行WebSocket 握手会直接失败。这是我当初踩过最深的坑之一希望你别再踩一次。3.2 团队项目和多环境Docker 是更靠谱的答案当部署从我一个人操作一台服务器变成团队成员频繁发版、多套环境并存裸机部署的短板就暴露了每个人装的依赖可能有差异服务器上的历史残留会影响新项目回滚非常痛苦。这时候 Docker 几乎是标准答案因为它把环境本身打进了镜像部署从还原环境再跑代码变成了拿镜像起容器。一个足够精简的 Node 镜像 DockerfileFROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . FROM node:20-alpine WORKDIR /app ENV NODE_ENVproduction COPY --frombuilder /app/node_modules ./node_modules COPY --frombuilder /app . EXPOSE 3000 CMD [node, app.js]这个 Dockerfile 用了两阶段构建第一阶段装依赖第二阶段只拷贝产物和node_modules镜像体积小很多。alpine基础镜像本身只有几十 MB对部署和传输都友好。如果项目还需要配套的缓存、数据库、反向代理这些服务用 Docker Compose 一起编排一套docker compose up -d就能把整个环境拉起来开发和生产的基线完全一致彻底告别我本机可以跑这种话。3.3 把重复劳动写成脚本一键部署的思路无论是 PM2 还是 Docker部署动作里总有重复的部分——拉代码、装依赖、重启服务、看状态。这些步骤一旦固定下来就该写成脚本否则每次手动敲总会有一天敲错一条命令。我现在的部署脚本大致逻辑是这样#!/bin/bash set -e APP_DIR/var/www/myapp BRANCH${1:-main} cd $APP_DIR git fetch origin git checkout $BRANCH git pull origin $BRANCH # 安装依赖 NODE_ENVproduction npm ci --omitdev # 数据库迁移如果有的话 # npm run migrate # 重启服务 pm2 restart myapp --update-env # 等健康检查通过 sleep 3 curl -fsS http://127.0.0.1:3000/health echo deploy okset -e是灵魂——任何一个步骤失败脚本立刻退出不会带着半成品状态往下执行。最后加一条健康检查 curl确保服务真的启动了而不是重启了个寂寞。4. 四次真实砸电脑事故的完整排查记录4.1 端口被占用却找不到凶手现象服务启动报EADDRINUSE端口 3000 被占用。我用netstat -anp | grep 3000查了半天什么都查不到。后来才知道服务器上可能有多个网卡或者 IPv6 地址netstat默认参数有时候会漏掉某些监听。换成ss -lntp一下就看到了一个旧的 PM2 进程占着端口。事后的处理很简单pm2 delete掉旧进程就行但排查过程让我养成了一个习惯——查端口优先用ss -lntp而不是netstat -anp前者信息更全显示 PID 也更干净。如果是某个未知进程占着端口又删不掉lsof -i :3000也能给出进程详情。4.2 内存悄悄涨满服务半夜被系统杀掉现象服务白天一切正常到了晚上访问量一高就挂。看 PM2 状态发现进程重启了十几次内存占用持续攀升最终触发 OOM 被杀。这种跑着跑着内存涨上去的案例十有八九是内存泄漏。快速定位的办法先用pm2 monit实时盯内存曲线确认是否单调上升再用调试协议连接进程做内存快照对比两次堆快照里哪个对象实例数量异常增长。我在实际项目里遇到过一个典型的泄漏点某个请求处理器里把数据缓存在一个全局 Map 里key 是请求 ID但请求结束之后从来没清理长时间运行下来 Map 越来越大。经验Node.js 的内存问题不要靠猜先确认是不是单增曲线再做堆快照对比。单纯把内存上限调大只是延缓爆炸时间治标不治本。4.3 环境变量在服务器上神秘丢失现象本地跑得好好的部署上去后数据库连接串、密钥这些通过.env读取的配置变成undefined服务直接报错。排查发现.env文件在.gitignore里压根没被提交服务器上就没有这个文件。这其实是好事密钥本来就不该进仓库。正确做法是把.env.example提交到仓库里当模板服务器上手动创建.env并填真实值部署脚本不碰这个文件。另外如果你的配置是通过环境变量注入的比如 Compose 文件的environment字段要确认变量确实传进了进程——可以在应用启动时打印一行不含敏感值的配置检查日志确认process.env里缺什么一目了然。4.4 升级 Node 版本后依赖编译崩溃现象某次我把服务器 Node 从 16 升到 18结果npm ci的时候一堆依赖开始编译报错报错信息全是 C 编译相关的错误。原因项目里有几个带原生模块的依赖比如某些加解密、压缩、图片处理库这些包在安装时会调用编译工具生成对应的二进制而编译产物和 Node 的 ABI 版本绑定。Node 大版本升级后 ABI 变了旧二进制不能复用必须重新编译但编译环境缺少 build 工具链于是全挂。解决方案分两步先把构建所需的基础工具装上然后清掉旧构建产物重新编译npm rebuild或者干脆删掉node_modules重新npm ci。从那之后我给自己立了个规矩Node 版本升级必须当成一次正式变更来对待先在测试环境验证依赖可安装再动生产。而用 Docker 部署之后这个问题基本没再出现过因为镜像里的 Node 版本和基础工具都是打包固定的。5. 部署上线后的三道防线日志、监控与回滚5.1 日志是事故现场的第一手证据部署完成只是开始。应用跑起来之后最重要的基础设施是日志。没有日志任何故障都是在黑盒里猜谜。用 PM2 的话pm2 logs myapp可以直接看标准输出和错误输出建议把所有业务日志写到统一目录并做日志轮转避免单个日志文件几个月后膨胀到几个 GB 拖垮磁盘。Node 侧也建议加一个成熟的日志库输出格式里带上时间戳、请求路径、耗时、错误堆栈。格式可以不统一但必须有时间和堆栈。我见过太多日志里只有一句话没有上下文的案例出了事根本没法定位。尤其多个实例跑的时候最好让每个请求带一个唯一的 trace id这样一条请求串起来的所有日志都能按 id 拉出来看。5.2 健康检查与自动重启让机器帮你先扛一轮应用上线后建议暴露一个/health健康检查接口返回 200 和基本状态即可。这个接口有三个用处部署脚本等待它返回来确认发布成功Nginx 或负载均衡可以用它判断节点是否存活外部监控工具定期探活挂了就报警。配合 PM2 的--max-memory-restart和 Docker 的restart: unless-stopped很多偶发性的挂死其实不需要人介入——进程被自动拉起健康检查很快恢复 200。要强调的是自动重启只是兜底它掩盖了症状但没治病根所以日志和监控仍然不能省至少你得知道服务挂过几次、为什么挂。5.3 回滚能力最不显眼但最保命的操作部署这件事还有一个经常被忽略的维度回滚。代码可以发布失败但不能无法复原。最简单的做法是版本目录结构——/var/www/releases/20250101_1200放当前版本current是个软链接指向它。发布时新目录构建好之后切换软链接再重启进程发现问题就切回上一个目录一条命令完成回滚。用 Docker 的话回滚更简单指定旧镜像 tag 重新启动服务就能回到上一个版本。这套能力平时用不上一旦用上就是救命。我给自己的纪律是任何部署方案如果不能在 5 分钟内回到上一个可用版本就不算完整的部署方案。最后说说我的体会。部署这件事其实没有那么多高深的东西翻来覆去就是环境、依赖、进程、代理、日志这几件事。但为什么每次都能把人搞崩溃因为大多数人太相信自己的记忆力今天改一个端口明天加一个环境变量后天更新一下 Node 版本每一步单独看都没问题合在一起就是灾难。我现在部署任何项目一定先写好清单版本锁定、依赖锁定、进程守护、代理配置、健康检查、回滚路径把这六件事确认完才敢上线。这套流程救过我很多次希望也能救你一次。 
长河君 · 2026/10/21 4:56:02 · 阅读 1.2k Node.js部署不再“砸电脑”：从环境锁定到进程守护的完整方案
如果你跟我一样写接口的时候觉得 Node.js 是全世界最好用的语言部署的时候又恨不得把电脑从窗户扔出去那这篇文章就是写给你的。Node.js 香在哪不用我多说——异步 IO 一个 Event Loop 打天下npm 生态要啥有啥前后端还能共用一套语言。但每次部署环境、依赖、进程、端口、代理这些问题就像约好了一样集体发作一次比一次让人血压高。这篇我不聊框架选型不聊性能调优就只聊部署这件事本身为什么会翻车、怎么排查、我现在怎么干。全文基于我部署过几十个 Node 项目的实际操作该给的命令和配置都会给到位。1. 真香是共识砸电脑也是共识部署为什么成了分水岭1.1 开发五分钟部署两小时香与痛的根源Node.js 为什么香开发体验太好了。代码写完npm start直接跑热重载一开保存即生效。没有编译步骤没有环境配置依赖缺失就npm install一下几秒钟搞定。但注意这种香是建立在开发机上的——你的电脑上已经装好了某个版本的 NodePATH里有一堆全局工具.env文件藏在项目目录里node_modules已经装得满满当当。这些东西凑在一起才让你觉得写起来真顺。但服务器是一张白纸。你要把一个在开发机上跑得欢快的 Node 项目搬到服务器上等于把一整套隐形环境全部重建一遍。Node 版本、npm 版本、依赖的编译工具链、端口占用、进程守护、反向代理、环境变量、日志目录……任何一环对不上应用就起不来或者半夜死掉。所以那句话怎么说来着本地跑通只证明你能跑服务器上跑通才叫部署完成。1.2 部署的本质把在我机器上能跑变成在任何地方都能跑我后来想明白一件事部署这件事本质上是把你开发时的个人环境翻译成一套可复现的公共环境。个人环境可以随意——Node 版本乱了就换依赖冲突了就删全局装了什么工具只有你自己知道。但公共环境必须确定因为你不是唯一维护这套系统的人而且服务器上没有你的肌肉记忆。从这个角度理解Node.js 部署痛并不怪 Node 本身而是大部分项目从来没人认真做过环境固化。如果你能用一套清单回答这三个问题——用哪个 Node 版本、装哪些依赖、怎么拉起进程——部署就成功了一半。这篇文章后边所有的方案都是在帮你把这三个问题变成固定的答案而不是每次部署时重新猜一遍。2. 部署现场最容易翻车的四个环节环境、依赖、进程、代理2.1 环境不一致我本机明明能跑这句话大概是部署事故里最经典的一句台词。你在本地开发时用的 Node 可能是 18甚至电脑上有四五个版本来回切换服务器上装的是系统源里的 Node 12。一跑起来ESM 语法报错、??操作符不识别、某些 API 不存在——你以为代码有问题其实是版本不对。解决办法其实很简单在项目根目录加一个.nvmrc文件里面写死 Node 版本号比如18.20.2。开发机上用 nvm 的人nvm use一下自动切版本服务器上部署脚本先执行nvm install读这个文件。另一个靠谱做法是把engines字段写进package.json并在.npmrc里设置engine-stricttrue这样依赖安装阶段就会强制检查版本版本不匹配直接报错而不是等启动时才炸。注意engine-stricttrue这个配置很容易被忽略但它的价值是让版本不匹配这个错误发生在最早期——装依赖时就报而不是跑起来才报。错误越早暴露排查成本越低。2.2 依赖装不对node_modules 成了玄学依赖问题比环境问题更隐蔽。最常见的是代码里用到了某个包但没写进package.json或者开发机上的node_modules里有旧版本代码在本地依赖了旧版本的行为上了服务器npm install装了新版本行为变了。还有一个经典翻车只提交了package.json没提交package-lock.json服务器上解析出来的依赖树跟本地完全不一样。正确的做法是package-lock.json必须提交进代码仓库服务器上安装依赖用npm ci而不是npm install。npm ci会严格按照 lock 文件安装速度比npm install快而且装完不会改 lock 文件。另外部署时记得区分生产和开发依赖——如果只是跑业务代码用NODE_ENVproduction npm ci --omitdev可以少装很多 devDependencies既省时间又省磁盘。2.3 进程没人管nohup 不是万能钥匙新手部署 Node 最常见的姿势是nohup node app.js 或者终端挂一个后台任务。当时确实能跑但问题是进程没人守护。Node 进程本身是单线程的一旦有未捕获的异常把进程带崩或者服务器重启你的服务就永远消失了直到有人发现网站打不开。这不是 Bug这是机制——Node 不会自动重启。所以进程守护必须交给专门工具。我最早用的是 PM2pm2 start app.js一行命令拉起进程pm2 save保存当前进程列表pm2 startup生成开机自启脚本配合--max-memory-restart做内存超限自动重启。后来上容器化之后进程守护这种事就交给容器的重启策略了。但不管用哪个方案原则是一样的你的 Node 进程必须有一个监护人能拉起、能守护、能重启。2.4 反向代理配置出错一切正常但你访问不了很多项目代码跑起来了日志也正常输出但浏览器一访问就 502。问题多半出在反向代理上。常见场景Node 服务监听在3000端口Nginx 把80端口转发过去但proxy_pass写错了路径或者http://127.0.0.1:3000;末尾多/少了一个斜杠行为完全不一样——带斜杠会替换匹配前缀不带斜杠则保留完整路径。这一类问题不看文档靠猜是猜不出来的。我的经验是代理配置写完先nginx -t测一下语法然后curl -I http://127.0.0.1:3000直连 Node 服务确认后端活着最后再curl -I http://服务器IP走代理链路。每一步分开验证出问题就知道卡在哪一段——是 Nginx 没起来、反代指向错了、还是 Node 服务本身没监听成功一步一个结论根本不用瞎猜。3. 我现在用的部署方案分场景给结论3.1 个人项目和小团队PM2 Nginx 完全够用先说结论如果你的项目是个人作品、小团队内部工具、或者访问量不太大的业务系统根本不需要一上来就上容器编排PM2 Nginx 这套组合最省心。具体步骤# 1. 安装 Node推荐用版本管理器或直接系统包管理装也行 # 2. 上传代码到服务器安装生产依赖 cd /var/www/myapp NODE_ENVproduction npm ci --omitdev # 3. 用 PM2 启动应用 pm2 start app.js --name myapp --max-memory-restart 512M pm2 save pm2 startupPM2 启动完之后pm2 status能看到进程状态和重启次数pm2 logs看实时日志。如果应用有多个实例需求可以用 cluster 模式pm2 start app.js -i maxPM2 会按 CPU 核数拉起多个进程共享同一个端口利用多核的同时还能做到滚动重启——一个实例挂了另外几个还在请求不会全部中断。然后是 Nginx 反代配置一个最小的 server block 长这样server { listen 80; server_name your-domain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }Upgrade和Connection这两个 header 不是可选项——如果你的应用用了 WebSocket比如实时推送、在线协作少了这两行WebSocket 握手会直接失败。这是我当初踩过最深的坑之一希望你别再踩一次。3.2 团队项目和多环境Docker 是更靠谱的答案当部署从我一个人操作一台服务器变成团队成员频繁发版、多套环境并存裸机部署的短板就暴露了每个人装的依赖可能有差异服务器上的历史残留会影响新项目回滚非常痛苦。这时候 Docker 几乎是标准答案因为它把环境本身打进了镜像部署从还原环境再跑代码变成了拿镜像起容器。一个足够精简的 Node 镜像 DockerfileFROM node:20-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . FROM node:20-alpine WORKDIR /app ENV NODE_ENVproduction COPY --frombuilder /app/node_modules ./node_modules COPY --frombuilder /app . EXPOSE 3000 CMD [node, app.js]这个 Dockerfile 用了两阶段构建第一阶段装依赖第二阶段只拷贝产物和node_modules镜像体积小很多。alpine基础镜像本身只有几十 MB对部署和传输都友好。如果项目还需要配套的缓存、数据库、反向代理这些服务用 Docker Compose 一起编排一套docker compose up -d就能把整个环境拉起来开发和生产的基线完全一致彻底告别我本机可以跑这种话。3.3 把重复劳动写成脚本一键部署的思路无论是 PM2 还是 Docker部署动作里总有重复的部分——拉代码、装依赖、重启服务、看状态。这些步骤一旦固定下来就该写成脚本否则每次手动敲总会有一天敲错一条命令。我现在的部署脚本大致逻辑是这样#!/bin/bash set -e APP_DIR/var/www/myapp BRANCH${1:-main} cd $APP_DIR git fetch origin git checkout $BRANCH git pull origin $BRANCH # 安装依赖 NODE_ENVproduction npm ci --omitdev # 数据库迁移如果有的话 # npm run migrate # 重启服务 pm2 restart myapp --update-env # 等健康检查通过 sleep 3 curl -fsS http://127.0.0.1:3000/health echo deploy okset -e是灵魂——任何一个步骤失败脚本立刻退出不会带着半成品状态往下执行。最后加一条健康检查 curl确保服务真的启动了而不是重启了个寂寞。4. 四次真实砸电脑事故的完整排查记录4.1 端口被占用却找不到凶手现象服务启动报EADDRINUSE端口 3000 被占用。我用netstat -anp | grep 3000查了半天什么都查不到。后来才知道服务器上可能有多个网卡或者 IPv6 地址netstat默认参数有时候会漏掉某些监听。换成ss -lntp一下就看到了一个旧的 PM2 进程占着端口。事后的处理很简单pm2 delete掉旧进程就行但排查过程让我养成了一个习惯——查端口优先用ss -lntp而不是netstat -anp前者信息更全显示 PID 也更干净。如果是某个未知进程占着端口又删不掉lsof -i :3000也能给出进程详情。4.2 内存悄悄涨满服务半夜被系统杀掉现象服务白天一切正常到了晚上访问量一高就挂。看 PM2 状态发现进程重启了十几次内存占用持续攀升最终触发 OOM 被杀。这种跑着跑着内存涨上去的案例十有八九是内存泄漏。快速定位的办法先用pm2 monit实时盯内存曲线确认是否单调上升再用调试协议连接进程做内存快照对比两次堆快照里哪个对象实例数量异常增长。我在实际项目里遇到过一个典型的泄漏点某个请求处理器里把数据缓存在一个全局 Map 里key 是请求 ID但请求结束之后从来没清理长时间运行下来 Map 越来越大。经验Node.js 的内存问题不要靠猜先确认是不是单增曲线再做堆快照对比。单纯把内存上限调大只是延缓爆炸时间治标不治本。4.3 环境变量在服务器上神秘丢失现象本地跑得好好的部署上去后数据库连接串、密钥这些通过.env读取的配置变成undefined服务直接报错。排查发现.env文件在.gitignore里压根没被提交服务器上就没有这个文件。这其实是好事密钥本来就不该进仓库。正确做法是把.env.example提交到仓库里当模板服务器上手动创建.env并填真实值部署脚本不碰这个文件。另外如果你的配置是通过环境变量注入的比如 Compose 文件的environment字段要确认变量确实传进了进程——可以在应用启动时打印一行不含敏感值的配置检查日志确认process.env里缺什么一目了然。4.4 升级 Node 版本后依赖编译崩溃现象某次我把服务器 Node 从 16 升到 18结果npm ci的时候一堆依赖开始编译报错报错信息全是 C 编译相关的错误。原因项目里有几个带原生模块的依赖比如某些加解密、压缩、图片处理库这些包在安装时会调用编译工具生成对应的二进制而编译产物和 Node 的 ABI 版本绑定。Node 大版本升级后 ABI 变了旧二进制不能复用必须重新编译但编译环境缺少 build 工具链于是全挂。解决方案分两步先把构建所需的基础工具装上然后清掉旧构建产物重新编译npm rebuild或者干脆删掉node_modules重新npm ci。从那之后我给自己立了个规矩Node 版本升级必须当成一次正式变更来对待先在测试环境验证依赖可安装再动生产。而用 Docker 部署之后这个问题基本没再出现过因为镜像里的 Node 版本和基础工具都是打包固定的。5. 部署上线后的三道防线日志、监控与回滚5.1 日志是事故现场的第一手证据部署完成只是开始。应用跑起来之后最重要的基础设施是日志。没有日志任何故障都是在黑盒里猜谜。用 PM2 的话pm2 logs myapp可以直接看标准输出和错误输出建议把所有业务日志写到统一目录并做日志轮转避免单个日志文件几个月后膨胀到几个 GB 拖垮磁盘。Node 侧也建议加一个成熟的日志库输出格式里带上时间戳、请求路径、耗时、错误堆栈。格式可以不统一但必须有时间和堆栈。我见过太多日志里只有一句话没有上下文的案例出了事根本没法定位。尤其多个实例跑的时候最好让每个请求带一个唯一的 trace id这样一条请求串起来的所有日志都能按 id 拉出来看。5.2 健康检查与自动重启让机器帮你先扛一轮应用上线后建议暴露一个/health健康检查接口返回 200 和基本状态即可。这个接口有三个用处部署脚本等待它返回来确认发布成功Nginx 或负载均衡可以用它判断节点是否存活外部监控工具定期探活挂了就报警。配合 PM2 的--max-memory-restart和 Docker 的restart: unless-stopped很多偶发性的挂死其实不需要人介入——进程被自动拉起健康检查很快恢复 200。要强调的是自动重启只是兜底它掩盖了症状但没治病根所以日志和监控仍然不能省至少你得知道服务挂过几次、为什么挂。5.3 回滚能力最不显眼但最保命的操作部署这件事还有一个经常被忽略的维度回滚。代码可以发布失败但不能无法复原。最简单的做法是版本目录结构——/var/www/releases/20250101_1200放当前版本current是个软链接指向它。发布时新目录构建好之后切换软链接再重启进程发现问题就切回上一个目录一条命令完成回滚。用 Docker 的话回滚更简单指定旧镜像 tag 重新启动服务就能回到上一个版本。这套能力平时用不上一旦用上就是救命。我给自己的纪律是任何部署方案如果不能在 5 分钟内回到上一个可用版本就不算完整的部署方案。最后说说我的体会。部署这件事其实没有那么多高深的东西翻来覆去就是环境、依赖、进程、代理、日志这几件事。但为什么每次都能把人搞崩溃因为大多数人太相信自己的记忆力今天改一个端口明天加一个环境变量后天更新一下 Node 版本每一步单独看都没问题合在一起就是灾难。我现在部署任何项目一定先写好清单版本锁定、依赖锁定、进程守护、代理配置、健康检查、回滚路径把这六件事确认完才敢上线。这套流程救过我很多次希望也能救你一次。