chrome devtools断点调试可精准停住执行、查看实时作用域、单步跟进，比console.log更有效；需正确配置sourcemap、合理使用debugger语句、善用console面板修改变量及network面板定位请求源头。
在Chrome DevTools里打断点调试console.log替代不了的逻辑问题
断点比console.log更精准，能停住执行、查看实时作用域、单步跳入函数内部。打开DevTools（F12或Cmd+Option+I），切到Sources面板，找到对应JS文件（可能在Page、Snippets或Content scripts下），点击行号左侧空白处即可添加断点。
常见卡点：
- 源码是打包后的（如
bundle.js），找不到原始.ts或.jsx文件 → 确保构建时生成sourceMap，且浏览器未禁用（Settings > Preferences > Enable JavaScript source maps） - 断点打上但没触发 → 检查是否在异步回调里（如
setTimeout、fetch.then），或脚本尚未加载完成就打了断点 - 想在DOM元素事件触发时停住 → 右键该元素 →
Break on > attribute modifications或event listener breakpoints里勾选click等类型
用debugger语句触发断点比手动找文件更直接
在代码里写debugger;，运行到这行就会自动停在Sources面板。适合快速验证某段逻辑，尤其在动态加载的模块、内联脚本或无法直接访问源文件的场景下。
注意点：
-
debugger是语句，不是函数，末尾必须有分号 - 上线前务必删掉，否则用户打开DevTools也会中断执行
- 若没生效，检查是否被压缩工具移除了（如Terser默认会删
debugger，需配置drop_debugger: false）
修改变量值和临时执行代码要用Console面板配合Sources的当前暂停上下文
断点暂停后，Console面板的执行环境就是当前作用域，可以直接读写变量、调用函数，不用再复制粘贴表达式。
实操建议：
- 想改某个
let count = 5为10？直接在Console输count = 10回车，继续执行就能看到效果 - 想测试一个条件分支是否走通？在Console里调用
someFunction(true)，观察返回值或副作用 - 避免在Console里定义新
const或function，它们不会注入到暂停的执行上下文中，只存在于Console自己的全局作用域
网络请求失败时，Network面板里的Initiator列比报错堆栈更早定位JS源头
当fetch或XMLHttpRequest失败，在Network面板点开具体请求，看Initiator列——它会显示是哪个JS文件第几行发起的，点击还能直接跳转到Sources对应位置。
这个信息常被忽略，但它能绕过“控制台只报Failed to fetch”的模糊提示，直接锁定问题代码行。特别适用于：
- 第三方SDK内部发起的请求失败，堆栈不透出真实调用点
- 多个
fetch链式调用中，不知道哪一环出了错 - 请求URL拼接错误，但
console.log没打全，而Initiator旁的Preview或Response标签页能立刻看到实际发出去的地址和返回体
真正难调的往往不是语法错误，而是执行流没走到预期位置、变量在某个中间状态被意外覆盖、或者异步时机导致的竞态——这些都得靠暂停、观察、微调，而不是重刷页面再猜一次。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
