做前端快十年了，占我工作时间最多的，不是写代码，而是排查 bug。你一定也有过这种经历：页面某个交互突然没反应，接口返回的数据渲染不对，你下意识打开控制台，狂刷 console.log，一条一条看输出，半小时过去了，真相还没浮出水面。
调试这件事，真的是拉开前端效率差距的分水岭。同一个诡异问题，有人靠最朴素的方式硬猜，有人却能在几分钟内通过几个“教科书里不常写”的偏方直接锁定根因。经常有朋友问我，前端面试题里那些调试知识点到底该怎么落地，我一般都会说：先从这九个偏方开始。今天我就把自己这几年实战中最常用的 9 个前端调试偏方整理出来，每个都在真实项目里救过场。它们覆盖四类场景：控制台操作、断点机制、网络与性能、框架组件调试，适合所有一线前端，尤其是经常被各种玄学 bug 折磨的人。
我整理这些偏方的逻辑，不是像官方文档那样把 DevTools 每个按钮都讲一遍，而是从实际痛点出发：日志太乱怎么整理？断点怎么打得聪明？请求从哪发起的？性能瓶颈怎么快速定位？把这几个问题解决了，你的调试效率至少翻一倍。
1. 为什么调试“偏方”比“正规军”更管用？先搞懂调试的三个层次
很多人第一次看到这些偏方，会觉得也就是几个小技巧，好像自己也会。但真正拉开差距的，不是“会不会用”，而是“遇到什么场景该用哪一个”。所以我先梳理一下调试方法的三个层次，后面再讲具体技巧时，脉络会清楚很多。
第一层是日志层。依赖 console.log 在代码里到处埋点，打印变量，拿到什么看什么。这是绝大多数新手的默认选择。它的优点是简单直接，缺点也很明显：日志一多就刷屏，重要信息被淹没；而且有一部分 bug 根本不会留下日志痕迹，比如某个事件被莫名其妙触发，你连该在哪里打日志都不知道。
第二层是断点层。打开 DevTools 的 Sources 面板打断点，一步步执行，观察调用栈、作用域、闭包。这比日志高级得多，因为它让你看到代码运行的完整过程。但普通断点还不够聪明，尤其是当 bug 只在循环到某一次、某个特定参数、某种异步时序下出现时，你一路按“继续”按到手软，效率还是上不来。
第三层是精准定位层。这就是资深前端和普通开发的分水岭：不再是“我猜是这里”，而是“我让浏览器在满足条件时自动暂停”“我让控制台帮我追踪事件流”“我直接复制真实响应来构造现场”。今天要讲的 9 个偏方，本质上都属于这一层。
我自己的体会是，一旦习惯了这种“让工具帮你收集证据”的调试方式，再回头看 console.log 就会觉得力不从心。好比你要看监控录像，肯定不会从凌晨开始一帧一帧快进，而是直接拖动到出事时间点附近，再慢慢看。调试偏方就是帮你精准拖到那个时间点的快进键。
2. 控制台里的三个隐藏神器：$0、copy()、console.table
这一节先给三个最日常、最容易被低估的偏方，全部在 Console 面板里就能用，覆盖 DOM 操作、数据复制和日志输出这三个最让人头疼的场景。
2.1 偏方一：$0和$_，控制台里的魔法快捷变量
新手调试 DOM，第一反应永远是document.querySelector('#xxx')，然后赋给变量慢慢操作。这个写法没错，但在调试场景下太啰嗦了。Chrome DevTools 的 Elements 面板和 Console 面板是联动的，你在 Elements 面板里点击选中任意一个节点后，回到 Console 输入$0，直接就能拿到这个节点。
$0代表当前选中节点，$1是上一次选中的，$2是再上一次的，一共可以回溯 5 个历史节点。拿到引用后你可以立刻读写属性、查看样式、找父级：
$0.dataset; // 看自定义属性，排查状态绑定 $0.className; // 看类名，确认样式是否生效 $0.style.display; // 直接读内联样式 $0.closest('.card'); // 向上找最近容器有一次我排查移动端列表点击事件失灵，先在 Elements 面板选中目标节点，然后切到 Console 执行$0.dataset.clickState，看到值一直停在'false'，马上判断是状态更新的时序问题。整个过程不到 30 秒。如果你用 querySelector 从头写选择器，还得先找 container、再找列表、最后才能定位节点，速度完全差了一个量级。
$_这个魔法变量表示“上一条表达式的结果”。比如你在 Console 里算了一段数据，紧接着想基于它再做一层加工：
const arr = [1, 2, 3, 4, 5]; arr.map((n) => n * n); // 输出 [1, 4, 9, 16, 25] $_.filter((n) => n > 10); // 直接用上一步结果，得到 [16, 25]不用临时变量名，操作流畅很多，很适合在 Console 里做数据探查时连续推导。
2.2 偏方二：copy()，一键把接口数据复制到本地做 mock
控制台里查看一个大对象，最常见的操作是：一层层展开，手选复制，粘贴到编辑器里格式化再看。这种方式效率极低，而且容易漏字段。其实 DevTools 给我们内置了一个全局方法copy()，可以把任何值序列化并写入剪贴板：
copy({ name: '张三', age: 18, tags: ['前端', '调试'] });然后你直接粘贴到任何文本编辑器，会得到：
{"name":"张三","age":18,"tags":["前端","调试"]}我实际项目中用得最多也是最实用的场景，是从 Network 面板复制真实接口响应，然后改造成本地 mock 数据。以前为了 mock 一个返回列表的接口，我要去后端文档里找样例数据再手动组装；现在直接在 Network 面板里找到对应请求，右键 Copy -> Copy response，粘贴到本地 mock 文件里，修改几个字段就能用。哪怕字段特别多，也不怕漏。
还有个组合用法：有时候你已经拿到一个响应对象，但想在复制前先处理一下字段，可以这样：
copy(response.data.map((item) => ({ id: item.id, name: item.name })));用 copy() 之前有个小坑：循环引用的对象会直接报错。报错信息通常是Converting circular structure to JSON。这时候可以先JSON.stringify分段测试，找到循环引用的源头再处理。
2.3 偏方三：console.table和console.assert，把日志从流水账变成报表
接口返回列表数据，用 console.log 打印，控制台会折叠成一行，必须手动展开才能看到每条对象的字段，数据一多眼睛都要瞎。但如果你换成console.table()，效果完全不一样：
const users = [ { name: '张三', age: 18, role: 'admin' }, { name: '李四', age: 30, role: 'guest' }, { name: '王五', age: 25, role: 'editor' } ]; console.table(users);控制台会渲染出一个表格，列名就是对象字段（name、age、role），每一行对应一条数据。前后端字段顺序、缺失字段、异常值在这些表格里一目了然。第二个参数还能限定列，比如console.table(users, ['name'])就只显示 name 列，信息更聚焦。
另一个偏方是console.assert(condition, message)。它不是总是输出，而是只有断言条件为 false 时才会打印错误日志。这很适合在代码里给关键逻辑加“语义检查”：
console.assert(cart.items.length > 0, '购物车不应该为空', cart); console.assert(order.status !== 'pending', '订单状态异常', order);正常情况下它是零噪声的，不会污染日志流；一旦出现异常状态，红色错误信息立刻跳出来。我在排查表单校验、购物车状态这类问题时经常用它，等于给代码加了几道临时保险丝。
3. 断点的高级玩法：条件断点、事件断点与 debugger 语句
很多人对断点的理解就是“在行号上点一下，会暂停”。但真正高效的断点，应该是“有选择地暂停”，要停就停在问题现场，不停在无关路径上。下面这三个偏方，帮你把断点从基础操作升级成精准武器。
3.1 偏方四：条件断点，只在符合条件时暂停
普通断点的痛点太明显了：循环 1000 次的代码，bug 只在第 999 次出现，你得一路按“继续”按到崩溃。DevTools 很早就支持条件断点，在 Sources 面板打开目标代码，右键点击行号区域，选择 Add conditional breakpoint，然后在输入框里写上任意表达式：
i === 999; // 或者更接近业务场景 user.status === 'vip' && order.total > 1000;只有表达式返回真，代码才会暂停在这里。这个特性相当于给断点加了过滤器，精准又省事。
我们项目里曾经有个排序算法，数据量特别大时某一种配置下结果才会出错。我在关键循环加了个条件断点data.length > 500 && data.some((item) => item.priority === 'high')，刷新一下页面，浏览器直接停在出错配置的那个实例上。要是用普通断点，我得手动在几百次循环里逐个观察，时间成本完全不可同日而语。
有一点要提醒你：条件表达式在每次执行到该位置时都会被求值，所以千万不要在里面写复杂的计算或者带副作用的调用，比如发起请求、修改全局变量、触发 console.log 等。否则你会在调试过程中引入新的问题。
3.2 偏方五：事件监听器断点，倒查事件到底从哪来
最让人头大的 bug，不是代码报错，而是“我不知道谁调用了它”。比如用户明明没有点击提交按钮，但请求发出去了；某个 keydown 事件不该在某个输入框里触发，结果偏偏触发了。这种问题你打日志不知道放哪，打断点也不知道打哪行，完全无从下手。
Chrome DevTools 的 Event Listener Breakpoints 就是为了解决这类问题。它在 Sources 面板右侧，列出了几乎所有浏览器事件类型，包括 Animation、Clipboard、Control、Keyboard、Mouse、Pointer、Touch、XHR/fetch、Timer 等。你勾选某一类事件，之后代码中任何地方触发了该事件，浏览器都会自动中断，并停在触发事件的那个位置。
我记得印象很深的一次排查：某个页面加载后，Network 面板里自动出现了一个 POST 请求，但用户根本没操作。我怀疑是某个初始化逻辑触发了提交，但不知道具体在哪。按照一般思路，我得去项目里搜所有可能的提交函数调用点，非常费劲。后来我勾选了 click 事件断点，刷新页面，浏览器立刻停在一个第三方库内部的 click 方法上。顺着调用栈往回看，找到了自己项目里的初始化逻辑，问题三分钟定位。
如果你想知道“哪一行代码发起了这个接口请求”，可以直接勾选 XHR/fetch 断点。重新触发请求后，浏览器会停在发请求的那一行，调用栈会清晰列出完整链路。这个方法在排查接口重复提交、请求竞态问题时尤其好用。
3.3 偏方六：debugger 语句，在源码里直接埋点
某些情况下，你想打断点都找不到地方。比如代码是动态生成的、经过 webpack 压缩处理的、或者位于 node_modules 里的第三方库里，打开 Sources 面板全是一堆压缩后的乱码。这种时候最干脆的办法，就是在源码对应位置手写一行debugger;。
function submitOrder(params) { const orderId = params.orderId; // 想在这里看 orderId 的具体值 debugger; // 浏览器执行到这里自动暂停 orderService.submit(params); }刷新页面后，只要执行到这一行，调试器就会暂停，你可以在作用域面板里查看当前所有变量。这个方法在调试小程序、本地调试构建产物、需要阅读第三方库内部逻辑时特别好用。
但这里必须划重点：debugger;是调试专用代码，一定不要留在生产环境。用户一旦打开 DevTools，遇到debugger就会强制暂停，体验很糟，也可能暴露实现细节。我个人的习惯是提交代码前全局搜索debugger全部清理，更稳妥的方式是在 ESLint 配置里开启no-debugger规则，让它直接在 CI 或 commit 阶段拦截住。
4. 网络与性能调试：Offline 模拟、copy(response) 与 performance.mark
前端调试并不只是调 JS 逻辑，网络请求状态和性能问题同样是 bug 高发区。这三个偏方专门处理弱网复现、接口复制、性能定位这类场景。
4.1 偏方七：Network 面板里的节流与 Offline 模拟，复现弱网现场
很多 bug 只在弱网环境下才会出现：资源加载超时、接口请求失败后的重试逻辑出错、图片懒加载在慢网下半天不显示、并发请求的顺序乱套。你本地网络太快，根本复现不出来，结果就是“用户那边有问题，我这边一切正常”。
DevTools 的 Network 面板左上角有一个网络环境选择器，默认是 No throttling，你可以在下拉菜单里切换 Fast 3G、Slow 3G，或者直接选 Offline。Fast 3G 能模拟约 1.6Mbps 的带宽和 150ms 左右的延迟，Slow 3G 就更慢一些。我调试接口超时和请求重试时，一般先切到 Slow 3G，再手动给接口加个 1 到 2 秒的延时，基本能稳定复现问题。
测断网场景就切 Offline，这对静态资源缓存、Service Worker、离线包、上报逻辑这类功能很有必要。你可以验证没网时页面到底应不应该展示、展示什么占位内容、缓存策略是否符合预期。
不过 DevTools 的节流只能模拟带宽和延迟，不能模拟丢包。如果你的业务在真实弱网上经常出现丢包导致的严重问题，还是得借助 Charles 一类系统级网络工具做更真实的模拟。日常快速排查场景，DevTools 内置的节流其实已经够用。
4.2 偏方八：performance.mark() 精准测量代码耗时
性能问题不报错，所以特别难定位。页面卡，项目大，哪个环节都像瓶颈。这种时候不要靠猜，直接用 Performance API 打点测时延：
performance.mark('task-start'); // 待测逻辑 for (let i = 0; i < 100000; i++) { calcSomething(i); } performance.mark('task-end'); performance.measure('heavyTask', 'task-start', 'task-end');在 Console 里执行：
performance.getEntriesByName('heavyTask');你会得到一条 PerformanceEntry 记录，它的 duration 字段就是这段代码从 start 到 end 的真实耗时，单位是毫秒。你可以在同一个流程里打多组标记，分别测不同步骤各占多少时间，从而把瓶颈彻底量化出来。比如一个初始化函数里，分别测量“数据请求”“数据处理”“DOM 渲染”三段，一眼看出谁最重。
配合 Performance 面板的时间轴，你还能看到标记点落在哪一段，进一步判断是主线程 JS 执行慢、页面布局重排频繁、还是网络加载耗时长。performance.mark本身非常轻量，不会明显影响性能。但正式发布前，我一般会把测试性质的埋点清理干净，只保留线上可观测性平台需要的标记，避免埋点太多影响后续维护。
4.3 偏方九：monitorEvents() 观测 DOM 事件流
最后一个偏方非常有“观察者”风格。如果说前几个偏方是打断点看代码，这个偏方就是开着探照灯看事件。在 Console 里执行：
monitorEvents(document.body, 'click');之后每次点击 body 区域，控制台都会输出该事件的详细信息，包括事件类型、target、timeStamp 等。你也可以同时监听多个事件、多个元素：
monitorEvents(document.querySelector('#app'), ['mouseover', 'touchstart', 'input']);这个偏方在排查事件顺序、冒泡路径、重复绑定问题时非常管用。有一次我调试一个拖拽组件，发现拖拽结束后总有一段多余的触发，感觉像是事件解绑不干净。用 monitorEvents 一测，touchmove 和 touchend 的触发顺序、次数全显示在控制台里，立马看出是某个 touchmove 监听没有在结束时移除。
用完记得执行：
unmonitorEvents(document.body);否则控制台会持续输出大量事件日志，一边拖慢页面速度，一边干扰后续排查。
有人可能会问，这个偏方和第 3.2 节的事件监听器断点功能重叠吗？其实两者不一样。事件断点主要帮你定位“代码中哪个位置触发了这个事件”，而 monitorEvents 更偏向“观察事件的发生时机和顺序”。一个用来切断路，一个用来做全程记录，可以搭配使用。
5. 框架开发者的“外挂”：React / Vue DevTools 的实战操作
如果你日常开发 React 或 Vue 项目，只靠浏览器 DevTools 是远远不够的。组件树、props、state、渲染性能这些东西，只有用框架官方配套工具才能看得顺畅。我把它们算成“框架级偏方”，因为它们解决的是浏览器 DevTools 管理不到的抽象层。
5.1 React DevTools：看组件状态、改 props，还能查渲染热点
React DevTools 安装后，浏览器 DevTools 面板会多出 Components 和 Profiler 两个标签页。Components 面板会展示完整的组件树，点击任意一个组件，右侧就能看到它的 props、state、hooks，以及从 context 中获取的值。
我最常用的操作是：当组件渲染出来的内容不对时，直接在组件的 props 或 state 面板里手动修改值，页面会实时响应。这样可以快速验证“是不是这个 prop 导致了渲染错误”，而不是回到源码里改代码再刷新页面，效率提高很多。
另一个很实用的功能是 “Highlight updates when components render”。开启后在页面上做交互，发生重新渲染的组件会以彩色框闪烁。如果你的页面有性能问题，用这个功能扫一遍，哪里过度渲染一目了然。Profiler 面板则可以完整录制一段交互过程中每个组件的渲染耗时，以瀑布图形式展示，能定位到“到底是哪个组件 render 最耗时”。这在排查 React 项目卡顿、首屏太慢时，是真正的救急手段。
5.2 Vue DevTools：历史状态回放和时间旅行
Vue 开发者可以装 Vue DevTools，除了看组件树和 props，它最有特色的功能是对状态管理的支持。在 Vuex / Pinia 面板里，你能看到所有状态变化的历史记录，点击任意时间点，状态树就会回到那一刻的 snapshot，这就是所谓的“时间旅行式调试”。
这个能力特别适合排查状态管理相关的 bug。比如某个数据操作后变成了 undefined，但你不知道是哪一个 action 改的。打开 Timeline 一层层回放，找到那个改变状态的记录，点进去看调用栈，就能确定是哪一行代码的问题。对 Vuex/Pinia 项目来说，这个偏方几乎是必备的。
React 和 Vue 的 DevTools 我都视作调试工具箱里不可缺少的一部分。因为它们操作的不是浏览器引擎层面，而是框架抽象层面，能帮你在大型组件树里快速精确地定位问题组件。
6. 这些偏方容易踩的坑，附避坑清单
最后，我把这些年实战中踩过的一些坑，以及容易忽略的操作细节整理成清单，大家在用前面这些偏方时能少走弯路。
- 用
$0前要确认当前焦点在 Console 面板。如果焦点还在 Elements 或 Network 等面板，输入$0自然无效。这个看起来是小事，但真有不少同事卡过。 copy()复制大对象时，循环引用会抛异常。可以先JSON.stringify看看到底哪段数据有问题，也可以主动传入一个 replacer 函数，把循环字段过滤掉。- 条件断点不要加在每帧都会执行的动画回调里。虽然表达式本身很快，但高频调用下仍会影响页面性能，让你在错误的现场状态中调试。
debugger;语句千万记得清理。我建议项目开启 ESLint 的no-debugger规则，提交前全局搜索一次，双保险。- DevTools 的网络节流只模拟带宽和延迟，不模拟丢包。实际网络环境差时遇到的问题，建议再考虑用 Charles 做更真实的弱网仿真。
monitorEvents()用完后必须unmonitorEvents()，否则控制台会被海量事件日志刷屏，页面还会明显变慢。- React DevTools / Vue DevTools 在普通项目和 iframe 场景下一般都能正常工作，但如果页面嵌在 webview 或混合应用环境，可能需要单独调试，不一定能直接挂载。
这九个偏方里，我实际最常回购的是$0、console.table和条件断点，因为它们几乎覆盖了日常 80% 的调试场景：操作 DOM、查看数据、精准暂停。剩下的几个偏方属于“特种工具”，用到的频率不高，但一旦遇到合适的场景，能省下成倍的时间。如果你刚开始练，先挑这三个高频的用熟，成本接近为零，效果立竿见影。调试工具说到底就是收集证据的手段，难点不是学工具，而是面对不同类型的 bug 时，你能快速判断该用哪一把钥匙。希望这份清单能帮你把下一道诡异 bug 的排查时间，压缩到原来的三分之一。
