启用“Uncaught promise rejections”断点可让DevTools在未处理Promise拒绝时立即暂停，配合unhandledrejection监听器和source map精准定位错误源头，需同时监听window.onerror与unhandledrejection以覆盖全部异常场景。
在浏览器断点调试中捕获全局未处理的异常错误，核心是结合运行时监听机制与 DevTools 的原生断点功能，而不是依赖单个 try/catch。重点不在“打断点的位置”，而在“让错误一发生就停下来”。
启用“Uncaught promise rejections”断点
这是最直接有效的调试手段。它能让 DevTools 在 Promise 被 reject 且尚未被 .catch() 或 await 捕获的瞬间自动暂停执行：
- 打开 DevTools → Sources 面板 → 右上角三个点 → “Breakpoints” → 勾选 Uncaught promise rejections
- 该断点会拦截所有未处理的 Promise 拒绝，包括 fetch 失败、res.json() 解析出错、手动 reject(new Error()) 等场景
- 暂停后可在 Scope 面板查看当前 Promise 状态，在 Call Stack 中回溯到原始调用位置
- 注意：需确保代码未被过度压缩（如禁用 Terser 的 drop_console 或 unused），否则变量名可能丢失
配合 unhandledrejection 全局监听器打印上下文
监听器本身不中断执行，但能提供结构化日志，辅助定位源头：
- 在页面加载早期（如 <script> 标签顶部）添加：
- window.addEventListener('unhandledrejection', event => {
console.error('❌ 未捕获 Promise:', event.reason);
console.error('→ 关联 Promise:', event.promise);
event.preventDefault(); // 仅调试时启用，避免控制台干扰
}); - event.reason 是实际错误对象（可能是 Error 实例、字符串或任意值），可展开看 stack；event.promise 可用于检查其状态和原型链
- 搭配 source map 正确加载，堆栈能精准映射到源码行（检查 Network 面板中 .map 文件是否 200 返回且路径正确）
区分 error 和 unhandledrejection 两类错误
很多开发者误以为 window.onerror 能捕获所有异常，其实它对 Promise 拒绝完全无效：
立即学习“Java免费学习笔记（深入）”；
- window.onerror：捕获同步错误、脚本加载失败、跨域资源错误（如 script 404）、语法错误等，但 不触发 于 Promise.reject()
- unhandledrejection：专为 Promise 设计，只在 reject 后无 .catch() / await try-catch 时触发
- 两者需同时监听，才能覆盖全部未处理异常场景
- 若使用第三方 SDK 或插件，建议在其初始化前注册这两个监听器，避免遗漏早期错误
避免静默吞掉错误
调试阶段不要随意调用 event.preventDefault() 或空 catch：
- preventDefault() 会屏蔽浏览器默认警告，但若没配套日志或断点，等于把错误“藏起来”
- 空 catch 或仅 console.log(err) 而不 inspect 堆栈，容易错过关键线索（比如 reason 不是 Error 实例，而是字符串或 null）
- 推荐做法：在监听器中加 debugger 语句，或直接在 DevTools 的 Console 中输入 debugger 触发断点，再手动检查 event 对象
- 上线环境应改为错误上报（如 sendBeacon），而非仅本地 console
