1. 未处理 Promise 拒绝Node.js 服务的隐形杀手在 Node.js 开发中Promise 已经成为异步编程的标准范式。但很多开发者可能没有意识到一个未被捕获的 Promise 拒绝Unhandled Rejection就像一颗定时炸弹随时可能让你的服务在毫无预警的情况下崩溃。这种情况我称之为静默自杀——服务看起来运行正常但实际上已经处于崩溃的边缘。1.1 为什么这是个严重问题从 Node.js v15 开始官方修改了默认行为任何未处理的 Promise 拒绝都会导致进程直接退出。这不是危言耸听而是实实在在的生产环境杀手。想象一下这样的场景凌晨 3 点你的服务突然崩溃自动重启后又立即崩溃日志中找不到任何明显的错误信息用户开始投诉服务不可用而你还在睡梦中毫不知情这种情况我见过太多次了而且往往发生在最重要的生产环境中。问题的根源通常是一些看似无害的异步操作比如发送邮件、写入日志或者调用第三方 API。2. 典型危险场景分析2.1 忘记 await 和 catch这是最常见的错误模式app.post(/api/notify, (req, res) { sendEmail(req.body.email); // 既没有 await 也没有 catch res.status(200).send(OK); }); async function sendEmail(email) { await smtpClient.send({ to: email, subject: Welcome! }); }这段代码看起来没问题但实际上非常危险。如果smtpClient.send()抛出任何错误网络问题、无效邮箱等就会产生一个未处理的 Promise 拒绝。2.2 Promise.all 中的部分失败await Promise.all([ fetchA(), fetchB(), // 假设这个失败了 fetchC() ]);如果fetchB()失败而外层没有 catch整个 Promise.all 的拒绝就会变成未处理的 Promise 拒绝。2.3 事件监听器中的异步错误emitter.on(data, async (d) { await process(d); // 如果 process 抛错没人 catch });这种错误特别隐蔽因为它完全脱离了主调用栈很容易被忽略。3. 防御策略四重保险3.1 第一重全局监听兜底在应用入口添加全局监听器process.on(unhandledRejection, (reason, promise) { console.error(Unhandled Rejection at:, promise, reason:, reason); // 这里应该接入你的监控系统如 Sentry、Datadog // 重要不要在这里直接调用 process.exit() }); process.on(uncaughtException, (err) { console.error(Uncaught Exception:, err); // 同上记录后考虑优雅关闭 });注意全局监听只是最后一道防线不能替代代码层面的错误处理3.2 第二重严格使用 await try/catchapp.post(/api/notify, async (req, res) { try { await sendEmail(req.body.email); res.send(OK); } catch (err) { logger.error(Send email failed, err); res.status(500).send(Failed); } });这是最基本的防御措施确保每个异步操作都有明确的错误处理路径。3.3 第三重显式处理 fire-and-forget 任务对于不需要等待结果的操作如日志、埋点也要显式处理错误sendAnalytics(event).catch(err { logger.debug(Analytics failed (ignored), err); });3.4 第四重静态检查工具配置 ESLint 规则{ rules: { require-await: error, no-floating-promises: error, typescript-eslint/no-misused-promises: error } }对于 TypeScript 项目可以利用类型系统提供额外保护async function dangerousOperation(): Promisevoid { // ... } // 编译器会提示未处理的 Promise dangerousOperation(); // 错误 await dangerousOperation(); // 正确 dangerousOperation().catch(() {}); // 正确4. 高级防御模式4.1 Promise.allSettled 替代 Promise.allconst results await Promise.allSettled([ fetchA(), fetchB(), fetchC() ]); const errors results .filter(r r.status rejected) .map(r (r as PromiseRejectedResult).reason); if (errors.length 0) { logger.error(Some tasks failed, errors); }4.2 异步重试机制对于关键操作实现自动重试async function withRetryT( fn: () PromiseT, maxRetries 3, delayMs 1000 ): PromiseT { let lastError: unknown; for (let i 0; i maxRetries; i) { try { return await fn(); } catch (err) { lastError err; if (i maxRetries - 1) { await new Promise(r setTimeout(r, delayMs)); } } } throw lastError; }4.3 事务性操作对于需要原子性的操作async function transactionalOperation() { let committed false; try { await beginTransaction(); // 一系列操作 await step1(); await step2(); await step3(); await commitTransaction(); committed true; } finally { if (!committed) { await rollbackTransaction(); } } }5. 监控与告警即使有了完善的防御措施仍然需要建立有效的监控日志聚合将所有服务的错误日志集中管理错误追踪使用 Sentry、Datadog 等工具追踪未处理异常指标监控监控进程重启次数、未处理拒绝数量等指标告警机制设置合理的告警阈值避免半夜被叫醒6. 实战经验分享在实际项目中我总结了几个关键经验不要相信这个操作不会失败网络、磁盘、第三方服务都可能失败每个 Promise 都需要归宿要么 await要么 catch要么明确传递全局监听不是万能药它只能告诉你出了问题不能防止问题测试是关键故意制造各种失败场景验证你的错误处理逻辑文档很重要在团队中建立明确的错误处理规范我曾经遇到过一个生产事故一个简单的忘记 await 导致服务每小时崩溃一次持续了三天才被发现。从那以后我在代码审查中特别关注 Promise 的处理情况。7. 工具推荐ESLint 插件eslint-plugin-promisetypescript-eslint/eslint-plugin监控工具SentryDatadogNew Relic测试工具Jest支持异步测试Sinon模拟错误TypeScript 配置{ compilerOptions: { strict: true, noUnusedLocals: true, noUnusedParameters: true, noImplicitReturns: true } }记住在 Node.js 的世界里没有无所谓的异步操作。每个 Promise 都需要明确的处理路径这是构建稳定服务的基础。