断点未生效通常因代码未执行、被JIT优化或sourcemap失效；应优先用debugger验证逻辑路径，禁用TurboFan优化，检查sourcemap配置，并在await行而非下一行设断点。
断点没生效，大概率不是浏览器问题，而是你设在了不会执行到的代码行、被优化掉的代码，或者根本没触发对应逻辑分支。
断点设在 console.log 之后就跳过了？
Chrome DevTools（以及大多数现代调试器）对「死代码」或「被 JIT 优化掉的函数」会跳过断点。比如函数内联、常量折叠后，原始源码行已不存在于实际执行流中。
- 确保目标代码确实会被执行：加个
debugger语句强制中断，验证逻辑是否走到这里 - 禁用 JS 优化：在 Chrome 中打开
chrome://flags/#javascript-harmony-shipping，关闭V8 TurboFan（仅调试时临时用） - 使用「黑盒脚本」功能排除第三方库干扰：右键 Sources 面板中的文件 →
Blackbox script
async/await 函数里断点不暂停？
断点设在 await 表达式之后，但调试器停在 await 前就继续执行了——这是因为 Promise resolve 后的微任务可能被调度到下一个事件循环，而断点未绑定到回调上下文。
- 把断点设在
await所在行，而不是下一行；DevTools 默认会在 await 暂停，但需确保没勾选Ignore list或启用Async stack traces干扰 - 在
await fetch(...)后加console.log('here')，再在该行设断点，比纯靠视觉定位更可靠 - 检查是否启用了
Disable async stack traces（Settings → Preferences → Sources），开启它才能看到完整的 await 调用链
断点灰色不可用（unbound breakpoint）？
灰色断点表示 DevTools 找不到对应源码位置，常见于：代码被 webpack/vite 编译、sourcemap 加载失败、动态生成的函数（如 new Function()）。
立即学习“Java免费学习笔记（深入）”；
- 确认
sourceMappingURL存在且路径可访问：在浏览器 Network 面板搜.map文件，看是否 404 或 MIME 类型错误 - 检查构建配置：Vite 用户确认
build.sourcemap: 'inline'或'hidden'；Webpack 用户确认devtool: 'source-map'且未被插件覆盖 - 避免在
eval()或模板字符串动态函数中设断点——它们没有 sourcemap 支持，断点必然失效
想在 DOM 变化时中断？别只依赖 debugger
手动插 debugger 不够智能，DOM 断点才是精准捕获修改时机的方式。
- 在 Elements 面板右键目标元素 →
Break on > attribute modifications（属性变更）、node removal（删除）、subtree modifications（子树变化） - 注意：这些断点只在 DevTools 打开时生效，且对
innerHTML批量更新可能只触发一次，而非每个属性 - 配合
console.trace()输出调用栈，比单靠断点更快定位是谁改了 class
document.querySelector('#app').addEventListener('click', () => {
console.trace('App clicked — who changed this?');
// 这里打 trace 比在下一行设断点更容易关联到真实修改源头
});
真正卡住你的，往往不是“怎么设断点”，而是“断点设在哪才真正代表你想观察的那个时刻”——DOM 更新、Promise resolve、Proxy trap 触发、甚至 requestIdleCallback 回调，各自有最合适的中断点，而不是统一往 console.log 下面点一下。
