HTML中设onclick断点无效，因HTML不执行逻辑，断点须设在handleClick函数体内；现代框架模板已编译为JS，原始HTML不存在；应使用Event Listener Breakpoints定位事件注册行，配合XHR/Fetch Breakpoints追踪异步链，Blackboxing过滤第三方脚本。
在 HTML 标签里设 onclick 断点根本停不住
HTML 本身不执行逻辑，onclick="handleClick()" 这类写法只是字符串，浏览器不会为它生成可中断的 JS 执行点。你点按钮后真正运行的是 handleClick 函数体——断点必须落在函数内部，而不是 <button> 标签上。
现代框架（React/Vue）更彻底：模板早被编译成 JS，原始 HTML 在运行时根本不存在。Elements 面板右键「Break on > attribute modifications」只能捕获 class 或 style 变更，对事件注册、数据更新完全无感。
- 内联事件绑定的执行路径：HTML 字符串 → 浏览器解析 → 动态生成匿名函数 → 调用你的函数名 → 真正执行
- 这个过程中，只有最后一步（调用你的函数）能被断点捕获，且依赖 Source Map 才能找到源码位置
- 如果用了压缩代码（如
react-dom.production.min.js），没 Source Map 就只能看到function(e){...}，没法定位业务逻辑
用 Event Listener Breakpoints 直接停在监听器注册行
这才是 Chrome DevTools 专为事件调试设计的正确入口。打开 Sources 面板 → 左侧展开「Event Listener Breakpoints」→ 勾选 click、input、submit 等具体类型，点击元素就会立刻中断在 addEventListener 调用的那一行。
- 优先勾选
Document和Element下的事件，避免被Window级全局事件干扰 - 对 Shadow DOM 内部元素，得先在 Elements 面板右键「Reveal in Elements panel」，再手动勾选其 scope 的事件类型
- 即使代码里写了
e.stopPropagation()，断点仍会触发，只是调用栈里能看到事件没冒泡上去
XHR/Fetch Breakpoints 抓住“点了没反应”的真实原因
很多所谓“事件没触发”，其实是后续异步链断了：点击 → 发请求 → 接口失败/超时 → 渲染逻辑跳过。这时候只盯事件监听器，永远找不到问题。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
在 Sources 面板 → XHR Breakpoints → 点「+」添加断点，填入接口路径关键词（比如 /api/order/submit），就能在 fetch() 或 XMLHttpRequest.send() 调用时立即中断。
- 留空字符串可拦截所有 XHR/Fetch 请求，适合快速排查是否发出了请求
- 如果断点没触发，说明连请求都没发出去——问题出在事件监听器注册失败，或条件判断提前 return
- 配合「Blackboxing」把
node_modules/和vendor/路径加进 Settings → «Ignore list»，避免单步调试时掉进lodash.js里出不来
别依赖 debugger 语句硬塞断点
在代码里写 debugger 确实能暂停，但极易遗漏、难以维护，而且上线前容易忘记删。更麻烦的是：它只在当前 JS 文件生效，对动态插入的脚本、eval 执行的代码、或框架自动生成的闭包无效。
真正稳定的做法是组合使用 DevTools 原生能力：Event Listener Breakpoints 定位事件源头，XHR/Fetch Breakpoints 追踪数据依赖，Blackboxing 过滤干扰，三者缺一不可。
复杂点在于：事件监听器可能注册在父元素（事件委托）、可能被多次移除再重绑、可能藏在 Promise 回调里。这时候单点断点必然丢失链条，必须靠调用栈 + 异步追踪（Async stack traces）来回溯完整路径。
