17370845950

浏览器断点调试比 console.log 更精准高效，支持暂停执行、实时查看变量、单步跟进；应于数据形态变化的关键节点下断点，如 API 返回后、状态合并前、DOM 渲染触发前。

直接在代码里下断点比 console.log 更准

浏览器开发者工具的断点调试能暂停执行、查看实时变量、单步跟进，比反复改 console.log 高效得多。关键不是“会不会用”，而是“在哪下、怎么下、为什么这里下”。

• 在源码面板（Sources 或 Debugger）中点击行号左侧空白处，打上蓝色圆点，执行到这行就会暂停
• 不要只在函数开头下断点——比如想查 fetch 返回值，断点要放在 .then() 回调内部，而不是 fetch(...) 那一行
• 右键断点可设「条件断点」，比如只在 user.id === 123 时触发，避免被大量无关请求打断
• debugger 语句是硬编码断点，但上线前必须删掉，否则用户打开控制台也会卡住

watch 表达式和 scope 面板比 console.log 看得更全

console.log 只能输出快照，而 watch 和 scope 是活的：变量改了，值立刻变；对象展开后属性增删也能实时响应。

• 在断点暂停状态下，右侧 Watch 面板点「+」可输入任意表达式，比如 response.data?.users[0].name，即使它还没定义也不会报错，只是显示 undefined
• Scope 面板自动列出当前作用域所有变量，包括闭包捕获的、let 声明的块级变量——这些用 console.log 很难一次性捞全
• 对大型对象，右键选择 Store as global variable，会生成一个临时变量如 temp1，接着就能在控制台里自由调用 JSON.stringify(temp1) 或遍历它的 key

network 面板配合 debugger 能定位异步逻辑断裂点

很多 bug 不是代码写错了，而是数据没来、格式不对、状态没更新。光看 JS 执行流不够，得把网络请求和 JS 执行串起来看。

• 在 Network 面板勾选 Preserve log，再勾选 Disable cache，确保看到真实请求
• 找到目标请求 → 右键 → Break on request fulfilled，这样响应一回来就自动断在 JS 处理它的那一行（比如 res.json() 后面）
• 如果接口返回 4xx/5xx，但代码里没处理错误分支，断点可能根本不会进 .catch() —— 这时要在 XHR/fetch Breakpoints 里手动加拦截规则，比如匹配 URL 包含 /api/user

Chrome DevTools 的 snippets 和 overrides 让调试不依赖改源码

改完代码要刷新、热更新慢、还容易误提交调试代码。snippets 和 overrides 是两个不改原始文件就能跑新逻辑的机制。

立即学习“Java免费学习笔记（深入）”；

• Snippets 在 Sources → Snippets 标签页里新建，写完按 Ctrl+Enter 运行，适合临时补一段 mock 数据或 patch 某个函数，比如重写 window.fetch 返回假数据
• Overrides 是真正持久化的本地覆盖：启用后，你修改的 JS/CSS 文件会自动保存到本地文件夹，并在页面加载时优先使用——这意味着你可以直接编辑压缩后的 main.min.js，加断点、改逻辑，且刷新不丢
• 注意：overrides 需要点「Allow local overrides」并选一个文件夹；snippets 不会污染生产代码，但别忘了删掉无用的 snippet，多了会干扰查找

最常被忽略的是：断点不是越多越好，而是在「数据形态变化的关键节点」下——比如 API 返回后、状态合并前、DOM 渲染触发前。盯着变量怎么一步步变成错的样子，比猜哪行日志该加更有用。