遇到 Node.js 进程因为 Promise 拒绝直接退出，不少人第一反应是给 process 加上 unhandledRejection 监听，让进程“别死”。这种第一反应本身没错，但动手前最好先确认当前环境到底是不是因为默认退出机制才停止的。下面是我平时排查的顺序，你可以参考。

先确认进程是退出还是只是报错

当 Node.js 进程收到一个未绑定 catch 的 Promise 拒绝时，会触发 unhandledRejection 事件。默认情况下，如果该事件没有注册任何监听器，进程会直接退出，并显示类似“UnhandledPromiseRejection”的错误信息。要确认当前运行环境是否启用退出行为，可以在入口文件顶部临时添加 process.on('unhandledRejection', () => {}); 观察进程是否继续运行。若继续，则说明默认行为已被抑制。

加一个空监听器看起来像在解决问题，但其实只是探路。如果加了之后进程仍然退出，说明不是默认策略导致的问题，需要看进程退出码和 stderr 里的完整堆栈。如果进程不再退出，说明问题确实出在 unhandledRejection 默认策略上。这时可以先记一下退出场景：是某条消息处理失败，还是定时任务触发的请求，还是启动阶段加载配置出错。场景不同，后续处理方式也不同。

关闭默认退出的两种常见入口

如果希望关闭默认退出行为，应在程序启动最早的阶段注册 unhandledRejection 的监听函数，例如：process.on('unhandledRejection', (reason, promise) => { console.error('Unhandled Rejection at:', promise, 'reason:', reason); });。注意，监听函数本身不能是 async 函数，也不要在其中抛出错误，否则会再次引发进程退出。也可以考虑直接通过命令行参数 --unhandled-rejections=warn 启动进程，这样既保留警告日志，又不中断运行。

两种做法区别在于：注册监听函数是你自己接管所有未处理拒绝，输出格式和后续动作都可以自定义；命令行参数则让 Node.js 按内置行为打警告。就我的经验，注册监听函数更灵活，但要小心别把错误吞掉。使用命令行参数时，进程不会退出，但每个未处理拒绝都会在 stderr 留下警告，适合临时排查。要注意的是，--unhandled-rejections 这个参数的具体表现，最好在你要上线的 Node 版本里实际跑一次，不同小版本处理方式可能有差异。

监听器不生效或重复注册的几个坑

常见的错误是把 process.on('unhandledRejection', ...) 放在某个模块的顶层，但该模块可能被延迟加载或多次初始化，导致监听器注册不生效或重复注册。另一个坑是使用空函数作为回调，例如 process.on('unhandledRejection', () => {});，这样做虽然不会崩溃，但错误被彻底丢弃，后续排查非常困难。应至少把 reason 和 promise 输出到日志中。

我见过有人把监听写在一个被循环加载的工具模块里，每次 import 都注册一次。重复注册并不会覆盖旧的监听，只会让回调执行多次，控制台里全是重复日志。更隐蔽的是延迟加载，入口文件先执行异步逻辑，某个模块后来才被 require，如果 unhandledRejection 在那一刻之前已经触发，监听器就来不及接住。所以尽量把监听放在入口文件最前面，紧跟着 require 之后，不要放在业务模块里。

关闭退出机制的风险边界

关闭 unhandledRejection 默认退出机制会掩盖真正的编程错误。当某个 Promise 被拒绝却没有处理时，很可能导致应用状态不一致、内存泄漏或未知的副作用。建议只在短生命周期任务、严格受控的执行环境或临时排查问题期间使用。对生产服务，更合理的做法是记录完整错误并调用 process.exit 或自定义恢复逻辑，而不是无脑地禁止退出。

这里说的“严格受控环境”，比如批处理任务、CI 脚本或一次性生成任务，这些进程生命周期短，即使有未处理错误，退出和不退出的差别不大。但常驻服务就不一样了。假设一个队列消费任务，某条消息处理时 Promise 被拒绝，你只记录日志不退出，进程仍然活着，但队列可能因为缺少 ack 或 offset 提交而反复拉取同一条消息，形成死循环。这种状态不一致很难一眼看出来。所以，全局监听器更适合做“最后一道防线”，比如先把错误细节写到日志，再决定是否退出。

更稳的做法：局部处理拒绝

除了全局关闭退出，还可以在 Promise 末尾显式追加 catch 来拦截拒绝，例如 promise.catch(e => logger.error(e))。对于异步函数，用 try/catch 包裹 await 调用。这种方法不会影响其他未处理的 Promise，也更适合长期维护。如果想让所有未处理拒绝只在开发时崩溃，可以使用环境变量 NODE_ENV 判断，或引入专门的错误处理工具库。

我通常会更倾向局部处理，因为你能明确知道是哪条链路出了问题。全局监听适合做兜底，比如把错误推给监控系统，然后仍然退出，避免带着脏状态继续跑。写成这样：process.on('unhandledRejection', (reason) => { logger.error(reason); process.exit(1); }); 相当于把默认退出的时机延后到日志落盘之后。

怎么验证自己的改动是否生效？我一般会在开发环境临时执行一个 Promise.reject(new Error('test'))，然后看进程是退出、打日志还是继续运行。确认后立刻删掉测试代码，再跑一遍原有用例。这里不用急着追求把所有错误都“接住”，先把行为摸清楚，再决定是局部 catch 还是全局兜底。