27.3 异步错误未捕获导致进程崩溃

Node.js 的异步编程模型虽然强大，但也埋藏着一个高频踩坑点：异步回调中抛出的错误如果未被恰当捕获，会直接导致进程崩溃。与同步代码中的 try/catch 可以轻易兜底不同，异步错误在调用栈上往往已经脱离了原始上下文，处理不当就会让整个应用意外退出。本节将详细解释这一现象的成因、常见场景，以及在生产环境中如何防御和处理。

27.3.1 进程为何会崩溃：从 EventEmitter 到进程级错误

在 Node.js 中，未经捕获的异步错误有两个主要的出口：

uncaughtException：当错误通过 throw、异步回调直接抛出，或者通过 EventEmitter 发射的 'error' 事件无人监听时，Node.js 进程会触发 uncaughtException 事件。如果此时没有任何监听器处理该错误，进程将立即打印错误堆栈并退出。
unhandledRejection：当 Promise 被拒绝（reject）且没有对应的 .catch() 或 await 承诺的处理时，会触发 unhandledRejection 事件。同样，没有监听器则会打印警告（Node 15 以后默认会导致进程退出）。

对于生产环境，进程崩溃意味着服务中断，所有正在处理的请求都会丢失。因此理解异步错误的传播路径并做好全局兜底，是保证稳定性的基础。

用一个简单的例子演示：

// 模拟异步回调中抛出错误
setTimeout(() => {
  throw new Error('定时器中的错误');
}, 1000);

console.log('进程仍在运行');

运行这段代码，一秒钟后进程直接打印错误堆栈并以非 0 状态码退出。这是因为 setTimeout 的回调执行时，调用栈已经回到事件循环顶层，try/catch 无法跨越异步边界。

同样，未处理的 Promise 拒绝：

new Promise((resolve, reject) => {
  reject(new Error('Promise 拒绝'));
});
// 没有 .catch()

Node.js 会输出一个警告 UnhandledPromiseRejectionWarning，并在后续版本中导致进程退出。

27.3.2 常见遗漏场景

实际开发中，异步错误未捕获往往不是故意的，而是由于对异步接口的错误处理约定不熟悉，或者疏忽了某些边缘情况。下面列举最常踩的几种坑：

1. 回调函数中的错误处理遗漏

Node.js 的许多传统接口采用错误优先的回调（error-first callback）约定：回调的第一个参数是 err，必须检查它。如果不检查，后续代码可能在空值或错误状态下继续执行，最终导致莫名其妙的崩溃。

const fs = require('fs');

fs.readFile('/nonexistent/file.txt', (err, data) => {
  // 忘记检查 err，直接调用 data.toString() 会导致 TypeError
  console.log(data.toString());
});

正确的做法是：

fs.readFile('/path', (err, data) => {
  if (err) {
    console.error('文件读取失败：', err.message);
    return;
  }
  console.log(data.toString());
});

2. EventEmitter 错误事件未被监听

许多内置对象如 http.Server、net.Socket、stream.Readable 都是 EventEmitter 的实例，它们在遇到错误时会发射 'error' 事件。如果没有为 'error' 注册监听器，Node.js 会将其作为未捕获异常处理，直接杀死进程。

const net = require('net');
const client = net.createConnection({ port: 9999 }); // 未监听的端口
// 没有 client.on('error', ...)

这会导致进程崩溃。解决方式是永远为可能出错的 EventEmitter 绑定 'error' 事件：

client.on('error', (err) => {
  console.log('连接错误：', err.message);
});

3. 异步迭代器未处理拒绝

使用 for-await-of 迭代异步可迭代对象时，内部的错误也需要被捕获：

async function* generateErrors() {
  yield 1;
  throw new Error('生成器内部错误');
}

(async () => {
  try {
    for await (let num of generateErrors()) {
      console.log(num);
    }
  } catch (err) {
    console.error('捕获到错误：', err);
  }
})();

如果外层没有 try/catch，同样会导致未处理的 Promise 拒绝。

4. Promise.all 中的部分拒绝

当使用 Promise.all 时，如果数组中某一个 Promise 被拒绝，整个返回的 Promise 立即拒绝，其余 Promise 的结果将被忽略。如果这个拒绝没有被捕获，就会触发 unhandledRejection。

Promise.all([
  Promise.resolve(1),
  Promise.reject(new Error('失败')),
  Promise.resolve(3)
]).then(console.log); // 没有 .catch()

推荐使用 Promise.allSettled 或者为 Promise.all 添加 .catch()。

5. async 函数中丢失的返回值

某些情况下，开发者会在非 async 函数中返回一个 Promise，但调用方却没有处理拒绝：

function risky() {
  return new Promise((resolve, reject) => {
    reject(new Error('风险操作'));
  });
}

// 调用时未使用 .catch()
risky();

这段代码会触发 unhandledRejection。

6. 事件监听器内的异常

如果在一个 EventEmitter 的某个事件回调中抛出同步错误，该错误也会导致进程崩溃，除非在监听器内部自行捕获：

const EventEmitter = require('events');
const emitter = new EventEmitter();

emitter.on('data', () => {
  throw new Error('处理数据出错');
});

emitter.emit('data'); // 进程崩溃

合理的做法是在回调内部使用 try/catch 包装，或者确保全局兜底。

27.3.3 全局兜底策略

尽管我们应尽量在本地捕获错误，但在生产环境中还需要一层全局保护，作为最后的保险锁，防止意外崩溃并记录日志。

监听 uncaughtException 与 unhandledRejection

process.on('uncaughtException', (error) => {
  console.error('未捕获的异常：', error);
  // 记录日志、发送告警，然后优雅退出
  // 注意：此时进程状态可能不一致，建议重启
  process.exit(1);
});

process.on('unhandledRejection', (reason, promise) => {
  console.error('未处理的 Promise 拒绝：', reason);
  // 同样可记录日志，但不一定需要立即退出，视 Node 版本而定
});

重要：uncaughtException 是一个最后手段。Node.js 官方文档明确指出，在这个事件处理器中执行任意操作可能无法保证进程状态的一致性，因此通常的做法是记录错误并执行 process.exit(1)，依赖外部守护进程（如 PM2、容器编排）自动重启。不建议在 uncaughtException 中试图恢复应用运行。

使用 async_hooks 追踪上下文

在复杂应用中，要定位未处理 Promise 的具体来源有时非常困难。可以借助 async_hooks 模块或第三方监控工具（如 cls-hooked）来追踪异步上下文，为日志带上请求 ID，帮助快速定位问题。

框架级别的统一错误处理

现代 Node.js 框架通常都提供了集中的错误处理机制，利用它们可以减少漏网之鱼：

Express：在中间件链末尾定义一个错误处理中间件（四个参数）。
Koa：使用 try/catch 包装所有中间件，或在顶层监听 'error' 事件。
NestJS：使用异常过滤器（Exception Filters）捕获未处理异常。
Fastify：使用 setErrorHandler 统一处理错误。

这些框架内部的实现其实也是在全局兜底的基础上进行了更结构化的封装，确保每一个请求链上的错误都能被格式化后返回客户端，而不是让进程崩溃。

27.3.4 排查实践：从崩溃到定位

线上出现进程崩溃，第一步是获取完整的错误栈和日志。Node.js 进程退出时会打印错误栈到 stderr，示例：

/app/node_modules/某模块:42
    throw new Error('连接超时');
          ^

Error: 连接超时
    at Timeout._onTimeout (/app/node_modules/某模块:42:11)
    at listOnTimeout (internal/timers.js:557:17)
    at processTimers (internal/timers.js:500:7)

从栈信息可以定位到具体文件和行号。如果栈中出现了未标注的模块路径，检查是否使用了第三方包，更新版本或查看 Issues。

排查步骤建议：

确认崩溃频率和条件：是否在特定流量下出现？是否与某个依赖的新版本有关？查看监控中崩溃前后的流量、CPU、内存趋势。
检查日志：除了错误栈，还应注意 unhandledRejection 的警告（Node 15 前默认不退出），它可能早于直接崩溃出现。
复现与隔离：如果能在本地用相同参数复现，使用 node inspect 调试，或添加临时日志。若无法复现，可考虑在全局处理器中加入更详尽的上下文信息（如请求路径、用户 ID）。
修复与加固：在错误源头添加适当的错误处理，同时在全局添加兜底。
压力测试：修复后使用压测工具（如 autocannon）模拟高并发，确认没有残留问题。

27.3.5 开发中的预防守则

永远处理错误优先回调中的 err 参数，绝对不能省略。
为所有 EventEmitter 实例监听 'error' 事件，尤其是流、Socket、Server。
Promise 链必须以 .catch() 结束，或使用 async/await 时用 try/catch 包裹。
使用 lint 规则提醒：比如 eslint-plugin-promise 的 catch-or-return 规则，以及 no-throw-literal 等。
在代码审查中重点关注异步路径的错误处理覆盖，特别是涉及外部服务调用、文件 I/O、数据库查询的模块。
编写测试用例覆盖错误路径：确保你的单元测试模拟了连接失败、超时、拒绝等场景。

异步错误不是 Node.js 的缺陷，而是其异步本质带来的责任转交——开发者需要主动管理错误。养成良好的错误处理习惯，再辅以全局兜底和监控，就能把进程崩溃的风险降到最低，让 Node.js 在享受高并发的同时，也保持生产级别的稳定性。