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。










