JavaScript调试应优先使用断点和作用域面板：确保源码加载且sourcemap正确，善用条件断点、XHR/事件监听断点，结合Scope面板查变量作用域与this值，配合Network面板排查请求问题。
JavaScript 调试不靠 console.log 盲打，关键在用对断点和作用域面板——绝大多数卡壳问题，其实 3 分钟内就能定位到 undefined 或 this 绑定错的地方。
怎么在源码里下断点才真正生效
直接点击行号左侧设断点最常用，但容易忽略两个前提：源码必须已加载（webpack 或 Vite 项目要等 Sources 面板里显示的是原始 .ts/.jsx 文件，不是打包后的 bundle.js）；且脚本不能被 eval() 动态执行（否则断点会灰掉）。如果断点变浅灰色、点击无响应，大概率是 sourcemap 没配好或代码被压缩后未映射。
实操建议：
- Chrome 中按
Ctrl+P（Win）或Cmd+P（Mac）快速搜文件名，避免在混乱的webpack://目录里手动翻 - 右键行号 →
Add conditional breakpoint，填入user.id === 123这类表达式，比在代码里写if再debugger干净得多 - 遇到异步回调（如
setTimeout、Promise.then），优先用XHR/fetch Breakpoints或Event Listener Breakpoints → Timer，而不是盲目在回调里加断点
为什么 watch 表达式总显示 undefined
Watch 面板里输 data.list 却报 ReferenceError，通常不是变量不存在，而是当前断点停在了错误的作用域。比如函数 A 调用函数 B，断点停在 B 里，却想看 A 的局部变量 items——它根本不在 B 的词法环境里。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 看右侧面板的
Scope区域，展开Closure、Function、Global，确认目标变量在哪一层；this的值也在这一栏实时显示 - Watch 里不要输带副作用的表达式，例如
arr.pop()，每次刷新 Watch 都会执行一次，导致数据异常 - 想观察对象深层属性变化？用
console.table(data)替代反复展开，尤其适合数组或键值结构清晰的对象
network 面板里找不到 fetch 请求
代码写了 fetch('/api/user')，但 Network 面板过滤 fetch/XHR 却为空，常见原因是请求被拦截（如 Service Worker 缓存）、跨域失败静默丢弃，或请求发到了非 http:// 协议（如 file:// 协议下 fetch 被浏览器禁止）。
实操建议：
- 勾选
Preserve log，防止页面跳转后请求记录清空 - 右键某条请求 →
Copy → Copy as fetch，粘贴到控制台直接复现，排除前端逻辑干扰 - 若看到请求状态为
(canceled)，打开Initiator列，点进去看是哪行 JS 触发的——常是abortController.abort()或路由跳转时未清理请求
真正难调的从来不是语法错误，而是变量在某个闭包里被意外覆盖、async/await 链中某处没 catch、或者 localStorage 里存了个 undefined 字符串——这些都得靠断点停住那一刻的 Scope 和 Call Stack 来揪出来，而不是靠重刷页面猜。
