Promise.reject 没处理好的代价，比你想象的大

写前端这么多年，最怕遇到的不是接口响应慢，也不是逻辑太复杂，而是那种“本地跑得飞起，上线就飘红”的诡异状况。很多时候，罪魁祸首并非高深的架构问题，而是一个被习惯性忽略的细节：Promise.reject。

很多开发者对 Promise.reject 的理解停留在“手动抛错”层面，以为只要写了就能被捕获。事实是，在异步链条里，它是个容易“越狱”的罪犯。一旦没有正确的容器承接，它就会像一颗流弹一样击穿你的运行上下文，导致页面白屏或服务挂掉。

最常见的隐患隐藏在 async/await 写法中。当你写下这样的代码时：

async function submitData() {
  const res = await api.post('/user'); 
  processData(res);
}

如果 api.post 返回了一个 reject 状态，且函数外部没有包裹 try-catch，执行流会立即中断。这个错误不会像同步报错那样优雅地堆积在调用栈顶端，而是在控制台生成一条红色的 Uncaught (in promise)。这类报错往往一闪而过，或者是混在其他日志中，排查时极易被遗漏。你以为业务跑通了，实际上异常已经悄无声息地吞掉了后续逻辑。

比局部遗漏更危险的是“静默失败”。在长链式调用中，中间某个环节 return Promise.reject(...)，而链条末端忘记挂载 .catch() 方法。此时程序既没有抛出异常，也没有执行成功回调，界面处于一种“僵死”状态。用户点击按钮无反应，开发人员却查不到任何错误记录。这种问题在生产环境尤为致命，因为它意味着用户体验断裂，却没有任何报警信号告诉你哪里出了问题。

要解决这种不确定性，不能只依赖开发时的自测，必须给系统装上一个全局的“安全网”。在应用入口文件中，注册 unhandledrejection 事件是行业标准做法：

window.addEventListener('unhandledrejection', function(event) {
  // 上报监控平台
  reportError(event.reason);
  // 阻止浏览器默认打印红色警告，避免刷屏干扰
  event.preventDefault();
});

这段代码的价值在于兜底。无论是你自己写的模块，还是引用的第三方 SDK，只要产生未被捕获的 Promise 拒绝，这里都能拦截到。特别是在复杂的项目中，深层次的回调地狱里总有些边缘情况容易被疏忽，全局监听能确保这些“漏网之鱼”进入监控视野，而不是悄悄烂在控制台里。

此外，拒绝参数的类型选择也很关键。尽量使用 new Error() 对象进行 reject，而不是直接扔一个字符串。例如 Promise.reject(new Error('Network Timeout'))。这样做是为了保留堆栈信息（Stack Trace）。当线上报错发生时，Error 对象里的调用链路能帮你迅速定位到具体哪一行代码触发了拒绝，而如果只是字符串，你可能得花费大量时间人工还原上下文，效率大打折扣。

异步编程的本质，是对未来的预期管理。每一个 reject 都代表了一种可能发生的失败路径，它不应该被视为意外，而应被视为流程的一部分。把局部捕获与全局兜底结合起来，用 Error 对象丰富错误信息，才能让应用在出错时依然保持透明和可控。别让一个简单的拒绝，变成线上无法解释的事故。