温馨提示×

nodejs崩溃日志怎么分析

小樊
39
2026-09-11 12:06:55
栏目: 编程语言

分析 Node.js 崩溃日志(crash logs)通常是为了定位为什么进程退出在哪一行代码出错、以及如何修复。下面按「从现象到根因」的思路系统讲一下。


一、Node.js 崩溃的常见形式

  1. 未捕获异常(Uncaught Exception)
    Uncaught Error: something wrong
    at app.js:10:5
    
  2. 未处理的 Promise Rejection
    UnhandledPromiseRejectionWarning: Error: xxx
    
  3. Segmentation fault / 底层崩溃
    Segmentation fault (core dumped)
    
  4. 内存溢出(OOM)
    FATAL ERROR: Ineffective mark-compacts near heap limit
    
  5. 进程被系统或容器杀掉
    • 没有 Node 日志,只有 exit code 137(OOM Killer)

二、崩溃日志里最关键的几部分

以典型异常为例:

node:internal/process/esm_loader:74
    throw new Error('xxx');
          ^
Error: xxx
    at foo (/app/app.js:12:10)
    at bar (/app/app.js:20:5)
    at Object.<anonymous> (/app/app.js:30:1)

重点看:

1. 错误类型

  • Error / TypeError / RangeError
  • ECONNRESET / ETIMEDOUT(网络)
  • Cannot read property of undefined

2. Stack Trace(调用栈)

  • 最上面是出错位置
  • 往下是调用链
  • 只看自己代码,忽略 node:internal

3. 退出码(exit code)

退出码 含义
1 普通错误
7 未捕获异常
137 被 kill(OOM)
139 Segmentation fault

三、常见崩溃场景 & 分析方法

1️⃣ 未捕获异常

原因

  • 同步代码抛错
  • 没有 try/catch

分析

process.on('uncaughtException', (err) => {
  console.error('CRASH', err);
});

✅ 建议:

  • 只在“最后兜底”用
  • 真正修复是定位栈中最上层业务代码

2️⃣ Unhandled Promise Rejection

UnhandledPromiseRejectionWarning: Error: xxx

原因

  • async 函数没 await
  • .then().catch()

分析

process.on('unhandledRejection', (reason) => {
  console.error(reason);
});

✅ 建议:

  • 全局监听 + 日志
  • 不要吞掉错误

3️⃣ 内存溢出(OOM)

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed

分析

  • 是否有大数组 / 缓存无限增长
  • 是否闭包持有大对象

工具

node --max-old-space-size=4096 app.js
node --inspect app.js

✅ 用 Chrome DevTools 看 Memory 快照


4️⃣ Segmentation Fault

Segmentation fault (core dumped)

原因

  • 原生模块(C++ Addon)
  • Node 版本不兼容

分析

node --abort-on-uncaught-exception
gdb node core

四、实用分析工具

✅ 1. 崩溃日志增强

process.on('uncaughtException', e => {
  fs.writeFileSync('crash.log', e.stack);
  process.exit(1);
});

✅ 2. 生成 core dump

ulimit -c unlimited
node --abort-on-uncaught-exception app.js

✅ 3. 堆栈更清晰

node --stack-trace-limit=100 app.js

✅ 4. 生产环境建议

  • PM2 / Docker restart
  • Sentry / Ali Node / EasyMonitor
  • 日志带 requestId

五、分析流程总结(实战)

  1. 看 exit code
  2. 看错误类型
  3. 看最上面一行 stack
  4. 确认是业务代码还是依赖
  5. 是否能复现
  6. 加日志 / 断点 / core dump

如果你愿意,可以把真实的崩溃日志贴出来(脱敏后),我可以直接帮你定位是哪一类问题、怎么改。

0