17370845950

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 依赖没写全；工具只是放大镜，前提是你得知道眼睛该盯住哪块玻璃。