Docker容器内Node Express服务运行数小时后崩溃如何排查修复

• 先获取容器退出日志：执行docker logs <容器ID/容器名> --tail 1000，查看崩溃前的最终报错信息，重点关注数据库连接异常、内存溢出、未捕获异常类日志。
• 查看容器退出状态码：执行docker ps -a找到停止的容器记录，通过STATUS列的退出码快速定位原因：137代表容器因内存不足被系统强制杀死，1代表业务逻辑抛出未处理异常退出，0代表服务接收到停机信号主动退出。
• 监控运行时资源占用：通过docker stats实时查看容器运行时的CPU、内存使用率，确认是否存在内存持续上涨不释放、资源配额不足的问题，本地运行正常通常是因为本地资源充足，容器受限环境下问题更容易暴露。

你提供的服务代码存在多个会导致长时间运行后崩溃的问题：

• 数据库连接方案不合理：当前用的是单连接模式，长时间运行后很容易被数据库服务端主动断开，重连逻辑缺失，下次请求调用db.query会直接抛出异常触发全局错误导致服务停机，建议替换为数据库连接池，配置自动重连、连接超时回收参数，避免连接泄漏和断连问题。
• OPTIONS接口逻辑错误：当前OPTIONS请求的处理逻辑是直接清空people全表，正常跨域场景下浏览器会先发送OPTIONS预检请求，该逻辑一旦触发不仅会丢失全部业务数据，删除操作报错时也会直接导致服务崩溃，需要删除该业务逻辑，替换为标准CORS头返回即可。
• 全局错误处理逻辑存在缺陷：
  1. uncaughtException、unhandledRejection事件的回调参数不是信号量，直接传入closeProcess会导致参数错误，停机逻辑执行异常，需要单独捕获错误详情打印后，再传入合法信号量触发停机。
  2. 回调风格的db.end方法不返回Promise，外层加await不会生效，会导致停机时序混乱，资源未完全释放就提前退出进程。
• 建议新增定时内存占用打印逻辑，输出process.memoryUsage()的堆内存数据，确认是否存在内存泄漏问题，内存泄漏在短时间运行时很难发现，长时间运行后才会触发OOM崩溃。

• 调整容器启动命令：不要用npm作为启动入口，npm进程不会转发系统信号给子Node进程，会导致你写的优雅停机逻辑完全不生效，超时后Docker会强制杀死进程，建议直接用node <你的服务启动文件名.js>作为启动命令，用exec形式写在Dockerfile的CMD/ENTRYPOINT中，确保Node进程是PID1进程，能正常接收SIGTERM等信号。
• 配置自动重启策略：启动容器时添加--restart=always参数，服务崩溃后会自动重启，先保障业务可用性再排查根因。
• 不要移除所有容器内工具：npm等构建工具可以移除，保留curl、top、ps等基础调试工具，方便运行时排查问题。

内容的提问来源于stack exchange，提问作者Michael Gunyan