JavaScript调试应善用浏览器开发者工具的断点与作用域检查：Chrome中分三类有效断点——行断点（需点击可执行语句行号）、条件断点（右键编辑输入i===10等）、事件监听器断点（勾选click/fetch）；debugger需DevTools开启且启用source maps才生效；Chrome与Firefox在Watch表达式、异常捕获默认行为及eval调试支持上存在差异。
JavaScript 调试不是靠 console.log 硬扛，而是用浏览器开发者工具直接暂停执行、查看状态、修改变量——关键在于「断点」和「作用域检查」是否用对了地方。
怎么在 Chrome 中设置有效断点
打断点不等于随便点一下行号。真正有用的断点分三类：
-
行断点：点击代码行号左侧空白处，但要确认该行有可执行语句（比如
if、function、return），空行或注释行点不了 -
条件断点：右键行断点 → “Edit breakpoint”，输入条件如
i === 10，避免循环里反复停住 -
事件监听器断点：在 “Sources” 面板右侧的 “Event Listener Breakpoints” 里勾选
click或fetch，适合调试没源码的第三方按钮或接口调用
为什么 debugger 有时不生效
debugger 是硬编码断点，但它受运行环境和工具开关双重控制：
- 必须在开发者工具开启状态下才触发（关着 DevTools 时
debugger被忽略） - 如果代码被压缩（如
bundle.js），需确保开启了 “Enable JavaScript source maps”（在 Settings → Preferences → Sources） - 某些框架（如 React）的合成事件中，
debugger可能落在异步回调里，需配合 “Async stack traces” 查看真实调用链
Chrome 和 Firefox 的调试差异在哪
两者核心能力接近，但实操细节影响效率：
立即学习“Java免费学习笔记（深入）”；
- Chrome 的 “Watch” 面板支持直接输入表达式（如
Object.keys(state)），Firefox 需先在控制台执行再拖进 Watch - Firefox 的 “Break on caught exceptions” 默认关闭，Chrome 默认开启 —— 这意味着同一段
try/catch代码，在 Chrome 里可能意外中断，而 Firefox 不会 - 两者对
eval代码的调试支持不同：Chrome 能显示 eval 内容，Firefox 在 strict 模式下常显示为[VM]，无法跳转源码
function calculateTotal(items) {
let sum = 0;
for (let i = 0; i < items.length; i++) {
debugger; // 这里只在 DevTools 打开时暂停
sum += items[i].price || 0;
}
return sum;
}
最常被忽略的是：断点位置和当前执行上下文必须匹配。比如在箭头函数里设断点，却在外部函数作用域里查 this，看到的往往是 undefined 或意外对象 —— 这不是工具问题，是 this 绑定规则本身决定的。
