断点位置选错、忽略异步流、看错作用域、修改变量无效、未清理debugger是调试五大常见错误。应选原始源码设断、在异步回调内下断、悬停查变量、避免重赋值、提交前清除debugger和无效断点。
断点位置选错，调试等于白忙
在源码中随便点一下就加断点，是新手最常踩的坑。比如在压缩后的代码里打断点，或在动态生成的函数（如 eval、Function constructor）内部设断，Chrome 会找不到对应行，甚至跳转到错误位置。应优先在开发者工具的 Sources → Page 标签下，找到原始未压缩的文件（带 .map 映射或本地服务直连的源码），再在逻辑清晰的入口、条件分支前、变量赋值后下断点。
忽略异步执行流，断点“断丢了”
Promise、async/await、setTimeout、事件回调中的代码不会在当前调用栈执行，断点若只打在发起处（如 fetch() 调用行），后续 .then() 或 await 后的逻辑根本不会停。正确做法是：在异步回调体内明确打断点；对 Promise 链，可在每个 .then() 回调第一行设断；使用 async/await 时，在 await 后的语句行下断点，并开启开发者工具中的 Async call stack（右键调用栈可启用），才能看清完整链路。
变量作用域看错，以为值没变其实是看错了地方
断点暂停时，右侧 Scope 面板显示的是当前执行位置的词法作用域，但容易混淆：闭包变量、循环中 let 和 var 的差异、解构赋值临时变量等都可能让变量列表“不直观”。例如 for (let i = 0; i console.log(i), 0)，在定时器回调里打断点，看到的 i 是独立的闭包绑定值；而用 var 则始终显示最终值 3。建议：鼠标悬停变量名直接查看实时值，比依赖 Scope 面板更可靠；复杂结构用 console.table(obj) 辅助验证。
修改变量后没触发重计算，误判逻辑问题
在断点暂停时，你在 Console 中改了某个变量（如 arr.push(4)），但后续代码仍按旧状态运行——因为 JS 引擎已编译好执行路径，运行时不会自动“重读”被你手动改过的引用。尤其注意：修改对象属性或数组元素有效；但重新赋值整个变量（如 obj = {a:1}）只影响当前作用域的局部绑定，不影响外部传入的原始引用。真正想验证修复效果，应刷新页面 + 重新走流程，或在断点后单步执行并观察副作用（如 DOM 变化、网络请求发出）。
没关掉 debugger / 不清理残留断点，上线还卡住
debugger; 语句是硬编码断点，极易遗忘，上线后用户打开控制台就会卡死。务必在提交前全局搜索删除；CI 流程中可用 ESLint 规则 no-debugger 拦截。另外，长期开发易积累大量无效断点：Sources 面板左侧断点列表里灰色的（禁用）、跨域脚本里的、404 文件中的断点，都会拖慢调试体验。定期点击断点列表右上角的 ⋯ → Remove all breakpoints 清理，或右键单个移除。
