断点应打在最能验证假设的位置：函数入口查参数、循环开头观变量变化、异步回调内验数据序；禁用而非删除断点更安全；用Step Over跳过已知正确逻辑，Continue直奔目标场景；变量分析重过程而非终值，结合Scope面板与Console动态探查。
直接讲清楚操作逻辑和调试意图，比背步骤更让面试官信服。重点不是“怎么点”，而是“为什么这么点”“看到什么能推断什么”。
断点加在哪、为什么加
不要只说“在行号上点一下”。要说明断点位置的选择依据：
- 函数入口处：看参数是否符合预期，比如
sum(a, b)断在第一行，能立刻确认传入的是10和20，而不是执行完才看到结果 - 异步回调内部（如
then或事件处理函数）：验证数据是否按序到达，避免“变量 undefined”的盲猜 - 循环体开头：配合“Step Over”逐次观察每次迭代的变量变化，比在循环里反复停住更高效
跳出循环或跳过不关键步骤
面试常问“循环里断住了，怎么快速看到最终结果？”——关键不是“按 F8”，而是理解控制流意图：
- 用 Step Over（F10）：跳过当前行（包括函数调用），适合已确认逻辑无误的封装方法
- 用 Continue（F8）：直接运行到下一个断点，适合想跳过大量中间迭代，直奔最后一次循环或后续逻辑
- 临时禁用断点：右键断点 → “Disable breakpoint”，比删了再加更安全，尤其多人协作调试时
如何验证变量变化过程
很多候选人只盯着“最终值”，而面试官想看的是分析能力：
- 在 Sources 面板左侧“Scope”区域，实时观察 Local、Closure、Global 中变量的层级和值变化
- 在 Console 面板中直接输入变量名查看，甚至执行
JSON.stringify(obj)查看深层结构 - 对数组或对象右键选择“Store as global variable”，生成
temp1，方便后续在 Console 中反复操作
debugger 语句的合理使用场景
它不是替代图形化断点，而是补充：
- 动态条件断点：比如
if (i === 99) debugger;，比手动设条件断点更直观，适合调试循环中特定索引 - 代码不在 Sources 面板中显示时（如 eval、模板字符串拼接的 JS）：
debugger是唯一可靠入口 - 团队协作中留痕：“此处逻辑易错，已加 debugger 方便复现”，比注释更直接
