异常断点是在JavaScript抛出错误时自动暂停的断点，不依赖预设行号，专用于捕获未捕获或已捕获的异常；而普通断点需手动设置在特定行，按执行顺序暂停。
什么是异常断点，它和普通断点有什么区别
异常断点不是停在某一行代码上，而是当 JavaScript 抛出错误（throw）时自动暂停。它不依赖你预判哪行会出错，适合排查“页面突然白屏”“某个操作后控制台报错但找不到源头”的场景。
关键区别在于触发时机：debugger 或行断点是“主动设点、按序执行到就停”，而异常断点是“被动响应、一抛错就拦”。它能捕获未被 try/catch 拦住的错误（未捕获异常），也可选配捕获已被 catch 处理的错误（捕获异常）。
如何在 Chrome DevTools 中启用异常断点
打开 DevTools（F12 或 Ctrl+Shift+I），切换到 Sources 面板。在右上角找到「Pause on exceptions」图标（⚡ 图标，或带感叹号的暂停符号）。
- 点击一次：仅在未捕获异常（
Uncaught TypeError等）发生时暂停 - 再点击一次（图标变蓝）：同时在捕获异常（即进了
catch块）时也暂停 - 鼠标悬停该图标可看到当前状态提示，如
Pause on uncaught exceptions
注意：该设置是全局生效的，关闭 DevTools 后失效；刷新页面后仍保持开启状态。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
常见误用和容易忽略的细节
异常断点看似简单，但实际调试中常因以下原因“没反应”或“停错地方”：
-
Promise拒绝（reject）默认不会触发异常断点，除非你在catch里重新throw，或开启「Pause on caught exceptions」并配合Promise.catch()调用链 - 异步代码（如
setTimeout、fetch回调）中抛错，断点会停在回调内部，但调用栈顶部可能显示async function或task，需点开「Call Stack」面板逐层展开才能看到真实来源 - 某些框架（如 React）会把错误包裹进合成事件或生命周期钩子，导致断点停在
react-dom.development.js里——这时要结合「Scope」面板看error对象的stack属性，而不是只信暂停位置 - 如果断点频繁触发（比如轮询接口失败），可右键该图标 → 「Don’t pause on caught exceptions in these files」，排除第三方脚本干扰
什么时候该用 debugger 而不是异常断点
当你已经知道错误类型和大致范围（比如确定是 Cannot read property 'x' of undefined），但不确定是哪个调用传入了 undefined，这时异常断点作用有限——它只会停在报错那行，而你真正需要的是“在所有可能传参的位置都看看变量值”。
此时更适合：debugger 插入可疑函数入口、条件断点（如 obj == null）、或在调用链上游加日志断点（logpoint）输出参数。
异常断点真正的价值，是在你完全不知道错误从哪来、控制台只有一行红字、且复现不稳定的时候——它能强制把执行流拽到错误爆发的第一现场。
