前端面试考察断点调试重在逻辑而非操作，需按场景选断点类型、停住后聚焦Scope/Call Stack/Watch面板分析，并精准使用F11/F10/Shift+F11单步执行，避开console.log引用陷阱等高频误区。
JS 浏览器断点调试在前端面试中不是考“会不会点红点”，而是考你能否用断点还原执行现场、定位真实根因。面试官真正想听的，是你的调试逻辑——为什么在这设、停住后看什么、怎么排除干扰、如何验证修复是否到位。
断点类型必须分清场景，不能只说“我加过断点”
光说“我会用 Sources 面板”远远不够。要能对应问题选对断点：
-
行断点：适合已知出错位置，比如控制台报错指向
utils.js:42，直接点行号设断，看变量值是否异常 -
条件断点：循环或高频触发逻辑里避免反复中断，右键行号 → “Add conditional breakpoint”，填
i === items.length - 1捕获最后一次迭代 -
XHR/Fetch 断点：排查接口参数异常时，在 Sources 右侧 XHR Breakpoints 里加
/login，请求发起前就停住，能看清加密前原始数据 - 事件监听器断点：按钮点击没反应？Elements 面板选中按钮 → Event Listeners → 勾选 click，一触即停在 handler 首行，不靠猜注册位置
停住之后不看 Scope 和 Call Stack，等于白停
面试常问“断点停住了，接下来怎么做？”——答案不是“按 F8 继续”，而是聚焦三个面板：
- Scope 面板：立刻确认当前 this 指向（是 Window？undefined？还是目标实例？），查 local 变量是否为空、格式是否符合预期（如 token 是字符串还是 null）
-
Call Stack 面板：若报
Cannot read property 'data' of undefined，顺着栈向上点，找到调用链断裂处（比如btn.onclick = obj.fn后触发的fn()，this 已丢失） -
Watch 面板：手动加
JSON.stringify(params, null, 2)或location.search，比层层展开对象更直观，尤其适合观察动态拼接内容
单步执行不是乱按 F11，三键分工必须讲清楚
被追问“F10 和 F11 区别”却答成“差不多”，会直接暴露实操经验不足：
-
F11（Step Into）：要进函数内部看实现，比如
sign(data)返回空，必须进去查 data 是否传入、中间步骤是否被篡改 -
F10（Step Over）：确认无问题的工具函数（如
formatDate()、debounce()），整行执行完再停，避免陷入无关细节 - Shift+F11（Step Out）：已在多层嵌套里，不想逐行走完？一键跳出到调用它的那行，快速回到关键路径
高频陷阱题怎么答才显功底
面试官爱问“为什么 console.log(obj) 看到的值和断点里不一样？”——这不是考记忆，是考你是否踩过坑：
-
console.log(obj) 输出的是引用快照，后续修改会联动改变控制台显示，造成误判；应改用
debugger;或 logpoint 输出实时值 - DOM 变动找不到源头？不要在 JS 里盲目加断点，Elements 面板选中元素 → 右键 → Break on → subtree modifications，真实变更发生时立即捕获
-
this 失控别急着改代码先停住看 Scope，再追 Call Stack 找那个“没带点号”的调用（如
handler()而非obj.handler()），根源就在这里
