Node.js应用进程中止除内存泄漏外的其他原因有哪些

• 未捕获的异常与未处理的Promise拒绝
  Node.js默认策略下，未被try/catch捕获的同步异常、未注册unhandledRejection监听器的异步Promise拒绝，都会直接触发进程退出。部分第三方依赖也可能抛出未被上层业务捕获的异常。你可以通过临时注册全局异常监听逻辑记录完整错误栈：

process.on('uncaughtException', (err) => {
  console.error('未捕获异常:', err.stack)
  process.exit(1)
})
process.on('unhandledRejection', (reason, promise) => {
  console.error('未处理的Promise拒绝:', promise, '原因:', reason)
  process.exit(1)
})

注意生产环境不建议捕获异常后强行维持进程运行，避免出现不可预期的状态问题。

• 系统OOM杀手误杀
  哪怕你的Node进程自身内存使用稳定，若同一服务器/实例上其他进程占用内存过高，系统OOM杀手会根据优先级选择进程杀掉释放内存，Node进程可能被误杀。你可以检查/var/log/message中是否存在Out of memory: Kill process或Killed process关键字，确认被杀进程ID是否匹配你的Node应用ID。
• 显式进程退出调用
  业务代码或依赖的第三方库中可能存在process.exit()主动调用逻辑，在满足特定错误条件时会主动终止进程，这类逻辑通常会伴随自定义错误日志输出，可以结合应用自身的业务日志排查触发条件。
• 外部信号中断
  进程会因为收到系统信号中止，常见触发场景包括：运维手动执行kill命令、服务管理工具（systemd、pm2等）配置的异常停止策略触发、容器编排环境（K8s、Docker等）健康检查失败主动杀掉进程。你可以通过日志确认进程中止前是否收到SIGTERM、SIGKILL、SIGINT等信号记录。
• 系统资源限制触发
  最常见的是进程打开的文件描述符数量超出ulimit限制，高并发场景下默认1024的文件描述符上限很容易被TCP连接、文件读写操作占满，触发异常后未捕获就会导致进程退出。你可以用ulimit -n查看当前进程的文件描述符上限，也可以查看/var/log/message中是否有资源超限的相关记录。其他可能的限制还包括CPU使用时长超限、进程最大线程数超限等。
• Node.js runtime或原生扩展崩溃
  1. 特定版本的Node.js runtime存在已知漏洞，比如V8引擎、libuv库的底层问题，触发特定操作时会直接导致runtime崩溃，建议升级到当前大版本的最新LTS版本验证是否复现。
  2. 若应用使用了C/C++编写的Node原生扩展（比如数据库原生驱动、音视频处理、加密相关扩展），原生扩展中的段错误、内存访问错误会直接导致整个进程崩溃，这类错误无法被JS层面的异常捕获机制捕捉，日志中通常会出现segment fault相关记录。

内容的提问来源于stack exchange，提问作者Elson D'Sa