JavaScript调试应优先使用DevTools断点与作用域面板，配合debugger语句、条件断点、Watch表达式及console.table/group等精准定位问题，而非依赖console.log硬扛。
JavaScript 调试不是靠 console.log 硬扛，而是用好 DevTools 的断点和作用域面板——多数卡顿、值异常、异步错乱问题，90% 都能靠
debugger + 断点条件 + Watch 表达式当场定位。
Chrome DevTools 断点怎么设才不漏掉动态生成的代码
直接在源码行号左侧单击设断点，对静态脚本有效；但遇到 eval、Function 构造函数、或 Webpack/Vite 生成的 chunk（如 chunk-abc123.js），需用「事件监听器断点」或「XHR 断点」触发后再手动找行。
- 动态脚本中插入
debugger语句，比手动点更可靠，尤其在压缩后无行号映射时依然生效 - 右键断点 → «Edit breakpoint» 可加条件，比如
typeof data === 'object' && data.id === 42，避免在无关循环中停住 - 启用 «Blackbox content scripts» 和 «Ignore list»，过滤掉 node_modules 或第三方 SDK 的堆栈干扰
console.log 够用吗？什么时候必须换用 console.table / console.group
打印数组或对象结构时，console.log 容易误判嵌套深度或属性是否为 getter；console.table 对二维数据一目了然，console.group 则能折叠异步链路（如 Promise.then 块）。
-
console.table([{name: 'a', age: 20}, {name: 'b', age: 25}])比console.log更快识别字段缺失 - 在
fetch().then()开头加console.group('fetch user')，结尾配console.groupEnd()，避免多个请求日志混在一起 - 慎用
console.log(obj)：若obj后续被修改，控制台里展开看到的可能是修改后的值（引用传递），应改用console.log(JSON.parse(JSON.stringify(obj)))快照
async/await 和 Promise 链里的错误为什么总找不到源头
未被捕获的 Promise rejection 默认只在控制台报 Uncaught (in promise) Error: xxx，但堆栈常指向 Promise.then 内部，丢失原始调用位置。
- 在 DevTools «Console» 面板勾选 «Pause on caught exceptions» 和 «Pause on uncaught exceptions»，让执行停在 throw 那一行，而非 catch 之后
- 给每个
catch块加console.error(e.stack)，因为e.message常不带文件行号 - Vite 项目需确保
vite.config.ts中build.sourcemap: true，否则断点跳转会指向打包后代码
真正难的不是设断点，而是判断该在哪儿设——比如一个状态没更新，要先分清是 React state setter 没触发、reducer 返回了相同引用、还是 useEffect 依赖没写全；工具只是放大镜，前提是你得知道眼睛该盯住哪块玻璃。
