[!info] related notes

• 所属 MOC: DevTools Sources MOC
• 面板: Sources 面板
• 暂停后证据: 调用栈与作用域
• 方法论: Hypothesis-Driven Debugging

DevTools 断点调试

目标

断点不是“让代码停下来”本身，而是：

在最能区分调试假设的位置暂停，观察当时的输入、状态和调用路径。

行断点

已经知道可疑函数时，在关键语句前暂停。

适合验证：

• 参数是什么；
• 分支为什么走这边；
• state 在哪一步变错。

条件断点

高频代码只在某个异常条件出现时暂停。

例如循环 10000 次，只有 item.id === targetId 时关注。

这样能减少无关暂停。

DOM 断点

不知道是谁修改 DOM 时，可从 Elements 给节点添加：

• subtree modifications；
• attribute modifications；
• node removal。

浏览器会在造成修改的 JavaScript 路径附近暂停。

XHR / Fetch 断点

知道某类请求发生了，但不知道谁发起：

按 URL 片段设置 XHR/fetch breakpoint。

暂停后看 call stack，比全局搜索 fetch( 更直接。

Event Listener 断点

不知道谁响应 click/keyboard/timer 等事件时使用。

它适合找事件入口，不代表真正 bug 就在第一个 listener。

暂停后看什么

优先：

1. Call Stack；
2. Scope / local variables；
3. Watch expressions；
4. 当前 DOM/state；
5. Step over / into / out。

断点的价值最终来自这些证据。

下断点的顺序

最接近错误结果的位置
→ 如果触发太频繁，加条件
→ 如果不知道入口，用事件/XHR/DOM breakpoint
→ 暂停后沿 call stack 向上找来源

避免的做法

• 到处打几十个断点；
• 在时序敏感问题里长时间暂停后假设行为完全不受影响；
• 条件断点执行有副作用的表达式；
• 只看当前行，不看调用栈。

无提示执行检查

不看正文完成：

1. 用行断点观察一个函数参数；
2. 把它改成只在某个 id 时暂停的条件断点；
3. 用 XHR/fetch breakpoint 找一条请求是谁发起；
4. 用 DOM breakpoint 找谁修改了某节点；
5. 暂停后从 Call Stack 找到业务入口。