`unhandledrejection` 是浏览器中触发的全局事件，用于通知开发者存在未捕获的 promise 拒绝；它**不会中断脚本执行**，仅作为调试与监控机制，页面仍保持完全交互能力。
unhandledrejection 事件常被误解为“脚本崩溃信号”，但事实恰恰相反：它是一个非阻塞、纯通知型的全局 DOM 事件，设计初衷是帮助开发者发现并修复遗漏的错误处理逻辑，而非终止运行。
事件的“全局作用域”含义
文档中提到“sent to the global scope of a script”，这里的“scope”并非指 JavaScript 的词法作用域（如函数或块级作用域），而应理解为当前执行环境的全局对象（global object）：
- 在浏览器主窗口中，该对象是 window；
- 在 Web Worker 中，则是 self；
- 它们既是事件的目标对象（event.target === window），也是全局变量和方法的宿主（例如可直接调用 addEventListener()，等价于 window.addEventListener()）。
因此，以下两种写法完全等效：
addEventListener('unhandledrejection', handler); // 隐式绑定到 window
window.addEventListener('unhandledrejection', handler); // 显式绑定脚本是否继续执行？答案是：✅ 完全继续
一个被拒绝且无 .catch() 或 try/catch 捕获的 Promise，不会导致脚本停止、页面卡死或主线程退出。例如：
addEventListener('unhandledrejection', (e) => {
console.warn('Unhandled rejection caught:', e.reason);
e.preventDefault(); // 可选：阻止默认控制台警告（仅限部分浏览器）
});
Promise.reject('Oops! No catch');
console.log('This still runs ✅'); // ✅ 正常输出
setTimeout(() => console.log('And this too ✅'), 0); // ✅ 异步任务照常排队
// 后续同步/异步代码全部不受影响
document.body.innerHTML = '<h2>Page remains fully interactive</h2>';⚠️ 注意：虽然脚本继续运行，但未处理的 Promise 拒绝会触发浏览器控制台的黄色警告（如 Chrome 中显示 (index):1 Unhandled promise rejection: Oops! No catch），这既是提示，也是性能与健壮性风险信号——长期忽略可能导致静默失败、状态不一致或难以排查的 Bug。
对比 Node.js：关键差异
与浏览器不同，Node.js 默认将未处理的 Promise 拒绝视为严重错误（自 v15 起默认启用 --unhandled-rejections=throw），若未监听 process.on('unhandledRejection')，进程将在下一个事件循环结束时退出：
// Node.js 环境（无监听器时）
Promise.reject(new Error('Crash!'));
// → 未捕获 → 进程终止（除非显式配置 process.on('unhandledRejection', ...)）而浏览器始终保证运行韧性（resilience）：即使大量 Promise.reject() 未处理，页面仍可响应点击、滚动、网络请求等一切用户行为。
最佳实践建议
- ✅ 始终为关键 Promise 链添加 .catch() 或 await + try/catch；
- ✅ 在应用启动时注册 unhandledrejection 监听器，用于日志上报与监控（如 Sentry、自建埋点）；
- ✅ 谨慎使用 event.preventDefault()：它仅抑制控制台警告，不替代真正的错误处理；
- ✅ 切勿依赖 unhandledrejection 替代防御性编程——它是兜底机制，不是错误处理方案。
总之，unhandledrejection 是浏览器赋予开发者的“安全网”，而非“断路器”。善用它提升可观测性，但核心逻辑的健壮性，永远建立在主动捕获与合理降级之上。
