debugger语句需确保脚本未压缩、sourceMap开启、避免无条件循环触发；异步中注意执行时机，推荐条件断点；console日志过多时可用过滤、覆盖或console.table优化；Network面板需Preserve log并检查Provisional headers；Elements改样式需配置Workspace映射才能同步源码。
Chrome DevTools 的 debugger 语句怎么用才不卡死流程
在代码里写 debugger 是最轻量的断点方式，但它不是“放哪都生效”。常见问题是：写了没反应，或者刷新后直接卡住白屏——多半因为脚本没加载成功、被压缩混淆了，或执行环境不匹配（比如在模块未初始化时就触发）。
- 确保脚本是未压缩的开发版本，
sourceMap已开启，否则断点会跳到 bundle.js 第一行 - 避免在循环体内部无条件写
debugger，容易锁死标签页；改用条件断点：if (i === 42) debugger;
- 在异步回调中使用时，注意执行时机——比如
setTimeout里的debugger可能被浏览器节流，建议配合console.time()定位耗时阶段
如何快速定位 console.log 太多导致的性能拖慢
大量 console.log 不仅污染输出，还会显著拖慢 JS 执行，尤其在高频渲染或轮询场景。Chrome 89+ 默认对 console 方法做了轻量优化，但旧版或复杂对象仍会触发序列化开销。
- 用
console.table()替代多次console.log(obj)查看数组/对象结构，减少重复展开成本 - 禁用所有日志前先过滤：在 Console 面板左上角输入
-log（减号 + 关键词），可隐藏含该字符串的输出 - 临时屏蔽日志的最快方式是覆盖全局：
console.log = console.warn = console.error = () => {};，但别提交到生产环境
Network 面板里怎样抓到 fetch 和 XMLHttpRequest 的真实请求头
默认 Network 面板只显示最终发出的请求，但 fetch 或 XMLHttpRequest 的 headers 如果是动态拼接或由拦截器注入（比如 axios 的 interceptors.request），光看 Headers 标签页可能看不到原始设置值。
- 勾选右上角
Preserve log，防止页面跳转后清空记录 - 点击某条请求 → 切到
Headers标签 → 展开Request Headers下方的Provisional headers are shown提示，说明该请求尚未真正发出（常见于 CORS 预检失败或重定向中止） - 想看 JS 中实际传入的参数，直接在调用处打断点，检查
init对象或xhr.setRequestHeader()的调用栈
Elements 面板修改样式后如何同步回源码文件
在 Elements 面板改 CSS 能即时预览效果，但刷新即丢失。想持久化修改，得确认当前样式是否来自本地文件（而非内联 style 或浏览器默认样式）。
立即学习“Java免费学习笔记（深入）”；
- 右键元素 →
Break on > attribute modifications可捕获动态 class 切换，辅助定位 JS 控制逻辑 - 样式面板右侧若显示
file://或项目路径（如src/components/Button.css:24），双击属性名即可跳转到源码编辑器（需已配置 Workspace 映射） - 没配 Workspace？用
Ctrl+S（Win）或Cmd+S（Mac）可将当前 Elements 中的 HTML/CSS 更改保存为 patch，但不会自动写入磁盘文件
Uncaught TypeError: Cannot read property 'x' of undefined 出现时，与其反复刷新，不如直接在 Sources 面板里按 Ctrl+Shift+O 快速打开报错文件，把光标停在出错行左侧灰点打个条件断点：obj === undefined。 
