Chrome和Edge的调试工具，大概是前端工程师每天相处时间最长的东西。我早年只会按F12看一眼Console里的报错，遇到红字就截图发群里问，后来熟练到能在Network里抓包、在Sources里打断点、在Performance里录帧率，才发现DevTools这套东西用得好不好，直接决定一个Bug要排查半天还是一刻钟。正好陆陆续续有同事问我调试相关的问题，干脆把我在Chrome和Edge里最常用、最顺手的debug方法做一次汇总。这套内容不追求覆盖所有按钮，只讲我实际用过且验证过的，从快捷键到断点，从抓包到性能分析，再到移动端真机调试，你把这篇啃完，日常开发里至少九成的调试场景都能自己搞定。
Chrome和Edge的开发者工具虽然名字带两家，但因为都基于同样的内核底座，交互逻辑几乎一模一样，甚至Edge还点缀了一些自家的小功能。所以我不会刻意区分两家浏览器，凡是说“DevTools”的地方，默认两者都适用。这篇文章面向两类人：刚接触前端、想系统学调试的新手，以及用了很久工具但总觉得差点意思、想补漏的老开发。前者照着做能少走弯路，后者看下来大概率能发现一两个之前没用过的功能。
需要说明的是，调试本身是经验活，工具的每种能力都要落到真实场景里才有意义。所以我不打算写成官方文档式的逐项列举，而是把每一项技能都和一个高频问题挂钩，比如“页面卡顿怎么定位”“接口返回奇怪数据怎么抓包”“线上代码怎么打断点”，这样你下次遇到问题时能直接对应上该用哪个面板，少做无用功。
1. 调试前的基础功课
1.1 为什么Chrome和Edge的DevTools能当作一套用
很多同事问过一个问题：平时用Chrome调试，到了客户现场只有Edge，会不会不习惯？我的回答是，放心用。Chrome和Edge的DevTools在界面布局、快捷键、面板划分上基本一致，因为两者都出身于同一个开源内核生态，开发者工具的组件也有大量共通。这意味着你只要把一套练熟，换到另一套完全不需要重新学习。Edge里还内置了一些Chrome没有的小工具，比如某些便利的页面截图、全局搜索的入口位置略有差异，但这些都不影响核心调试逻辑。
这里有个容易被忽视的点：两套DevTools虽然长得像，但版本更新节奏不完全同步，偶尔会遇到某个新功能一边有了另一边还没有的情况。我的建议是，核心调试手法不要依赖太新的特性，比如某些实验性面板，今天能用不代表明天还在。反而是那些稳了很多年的基础功能——Console、Network、Sources、Performance、Memory——值得花时间吃透，它们才是日常debug的真正主力。
提示：调试时优先使用你熟悉的浏览器。只要页面能在Chrome或Edge的任意一个里正常打开，DevTools提供的绝大多数能力都是一致的，别把精力浪费在纠结哪家更好用上。
1.2 值得刻进肌肉记忆的快捷键
调试是高频率操作，每多一步鼠标点击就会打断一次心流。我把平常最常用的快捷键整理成了一张表，建议新人先把这些背下来，用熟了就会发现效率至少提升一个档次：
| 功能 | 快捷键（Windows/Linux） | 说明 |
|---|---|---|
| 打开DevTools | F12 或 Ctrl+Shift+I | 最基础，没有之一 |
| 元素选择器 | Ctrl+Shift+C | 直接进入页面元素快速定位模式 |
| 直接打开Console | Ctrl+Shift+J | 想只看日志时别从Elements切 |
| 搜索当前面板 | Ctrl+F | Elements里查节点、Network里查请求、Sources里查文本都可以用 |
| 搜索所有文件 | Ctrl+P | 按文件名快速打开源码 |
| 在全部代码中搜索 | Ctrl+Shift+F | 全局搜索关键词，适合找某个函数在哪个文件 |
| 切换设备模拟 | Ctrl+Shift+M | 调试移动端布局前奏 |
| 暂停/继续脚本 | F8 | Sources调试时最常用 |
| 单步跳过 | F10 | 一次执行一行，不进入函数 |
| 单步进入 | F11 | 进入函数内部逐步执行 |
这里说两个使用习惯。第一，Ctrl+F在DevTools的每个主要面板里都通用，但作用对象不同：在Elements里查DOM节点，在Network里过滤请求，在Sources里搜文件内容。很多新人只会在网页里用Ctrl+F，其实DevTools里这个快捷键的价值大得多。第二，F8功能很多人忽略，它不仅可以暂停JS运行，配合Sources面板，还能在代码执行到一半时手动中断，方便你观察那一刻页面状态。
我个人最依赖的组合是Ctrl+Shift+C去页面里选节点，选中后直接用$0在Console里操作它。这一套组合用下来，改样式、查内容、驱动脚本都非常顺手。快捷键这种事，光看不练假把式，建议每天故意用快捷键操作，逼自己把鼠标动作替换掉，一两周就能形成肌肉记忆。
2. Console不只会打印：日志与变量的进阶玩法
2.1 格式化、分组、计时，一套组合拳
很多人对Console的印象还停留在console.log("xxx")，其实它内置的API相当多，只是平时没被充分利用。
首先是格式化占位符。console.log支持类似C语言的%s、%d、%o占位符，可以拼出比字符串拼接更干净的日志：
const user = { name: '张三', age: 30 }; console.log("用户信息：%s，年龄：%d", user.name, user.age); // 输出：用户信息：张三，年龄：30 console.log("完整对象：%o", user); // %o 输出对象，可以展开看结构其次是有视觉分层的分组。项目里日志一多，Console就变成一锅粥。用console.group或者console.groupCollapsed可以把同一类日志折叠到一起，展开才看到细节，收缩时不占地方：
console.group("订单模块"); console.log("创建订单成功"); console.log("更新订单失败：库存不足"); console.groupEnd();第三是console.table。数组或对象数组的打印，table的表格化展示比log好看得多，几行数据一眼扫完，字段对齐清清楚楚：
const list = [ { id: 1, name: 'A商品' }, { id: 2, name: 'B商品' } ]; console.table(list, ['id', 'name']);再就是计时与计数。console.time和console.timeEnd可以快速测一段代码的执行耗时，不用自己手动拿Date.now()去算。console.count可以对某个事件发生的次数进行统计，比如调试循环体里某分支命中了多少次：
console.time("接口请求耗时"); fetch('/api/data').then(() => console.timeEnd("接口请求耗时")); function handleClick() { console.count("点击次数"); }这一套组合拳下来，日常日志输出基本够用。我自己的习惯是：需要展示多行数据优先console.table，需要观察耗时优先console.time，需要分模块聚焦时用console.group，而不是所有东西都堆成console.log。
2.2 让调试信息更有用处的几个冷门API
这里补充三个用过的场景，不新鲜但有效。
console.assert是“条件才输出”的日志。比如接口返回的数据结构和你预期不一致，希望只在异常时打印：
console.assert(response.code === 200, "接口返回异常", response); // 条件不满足时才会打印出错误信息，条件满足时静默console.dir会把对象以属性列表的形式展开。console.log打印一个DOM节点时会输出节点本身，但console.dir输出的是这个节点的所有可用属性和方法，非常利于检查元素对象的API字段。做前端开发时偶尔会遇到一个DOM元素不知道怎么取属性，console.dir一秒看清结构。
console.trace则能打印当前函数的调用链。这种方式适合回答“这个函数到底是由谁调用进来的”，比如一个数据上报函数在多个地方被触发，你想弄清楚当前这一次从哪进来的：
function trackEvent(name) { console.trace("事件触发:", name); }这三个API都要配合“在Console里观察输出”来理解。它们不会改变程序逻辑，只是在运行时给你多开几扇观察窗口。尤其是console.assert，很多人没用过，但它非常适合写业务代码时做快速断言，不用单独引入断言库。
2.3 把错误信息变成可捕获、可断点的信号
Console里的红字报错，很多人只是看一眼原因就结束了。但大多数时候你需要的是“断点停下来让你看现场”，而不是让代码直接跑完再回看日志。
DevTools的Sources面板顶部有一个“Pause on exceptions”开关，打开后脚本一抛出异常就会自动停在那一条代码上，此时调用栈、作用域、变量值全都冻结在崩溃现场，排查问题非常有优势。Console面板的右键菜单里也有类似的选项，可以针对“未捕获异常”或者“已捕获异常”分别设置。
结合这个思路：当线上代码报了一个不痛不痒的警告，你想快速知道它从哪来，就在Console中记录的堆栈信息里点文件链接跳过去。如果那个文件是压缩后的，找不到对应源码，那就先开启Source Map映射，再下条件断点。
注意：开“Pause on exceptions”前确认代码没有大量被捕获的异常，否则运行过程中会一直中断，反而干扰调试。如果只是想看报错堆栈，优先在Console里点击错误右侧的文件链接。
3. Elements与样式调试：改样式本来就该实时看效果
3.1 快速定位节点：别再用鼠标满页面找了
Elements面板的首要任务是定位页面上某个可见元素对应的DOM节点。四种方式我都有自己的适用场景：
第一种，页面右键菜单里的“检查”或者快捷键Ctrl+Shift+C，鼠标点到哪就高亮显示哪个元素，这是最直觉的方式。第二种，在Elements里直接用Ctrl+F输入CSS选择器，比如输入div.card > span.price，能按选择器搜索节点，适合你知道大结构但不想鼠标到处翻的情况。第三种，在Console里用$()或$$()选择器命令，比如$('div.card')返回第一个匹配节点，$$('div.card')返回所有匹配节点，而且这些节点可以直接在Console里操作属性。
第四种最关键：在Elements中选中一个节点后，它可以变成Console里的$0，上次选中的是$1，往前依次是$2、$3、$4。这是什么意思？比如你在Elements里点了一个按钮节点，然后切换到Console输入$0再回车，就能直接拿到这个DOM对象，对它执行$0.click()或者$0.innerText都不用重新选择。调试交互类问题时，这个技巧能省掉大量重复定位动作。
另外有一个右键功能我常推荐给同事：在Elements里选中节点，右键选择“复制”下的“复制JS路径”，它会生成一个document.querySelector表达式，可以直接粘到代码里作为定位依据。比自己手写选择器省事，也不会因为手误写错引号。
3.2 伪类状态、计算样式与盒子模型的正确打开方式
改样式是DevTools里最“所见即所得”的一类操作。你直接在右侧Styles面板里改属性值，页面立刻生效，不用刷新。但有几个细节值得说透。
第一个是伪类状态模拟。很多人会遇到hover、active这种只有鼠标悬停时才生效的样式，想在悬停状态下调试却不敢松手。其实右键节点，在Force state里把“:hover”勾上，页面就会停留在悬停状态，你可以放心慢慢改样式。类似的还有:active、:focus、:visited，甚至是自定义的伪类状态，一网打尽。
第二个是Computed面板。在Styles里看到的是样式声明，它们还要经过层叠、继承、计算才变成实际生效的样式。Computed面板显示的才是浏览器算出来的最终值。比如你怀疑某个font-size被覆盖了，就在Computed里查font-size，点开能看到它是从哪个选择器继承/覆盖来的，这个链条非常有排查价值。特别推荐在Computed面板里用右上角的过滤输入框，输入属性名就能快速过滤，不用滚长列表。
第三个是盒子模型。面板左上角的盒子图例可以直观看margin、border、padding、content四个区域的大小，你甚至可以点击色块直接修改数值，页面实时重排。这个对排查布局偏移、宽高计算不一致非常有效。
还有个经验：改样式只是在运行时改，刷新页面就全丢了。如果你确认某个改动是最终方案，记得回到编辑器把这些属性同步到源码里。我见过不少同事在DevTools里调了大半天，结果刷新后全没了，又要在编辑器里重新改一遍。
3.3 用DOM断点捕捉“谁改了节点”
有一种问题特别头疼：某个节点在某个时刻被框架或者脚本改掉了，你想知道是谁改的，但改代码的人自己也不知道。这时候用Elements面板的DOM断点能精确定位。
在节点上右键 → “Break on”，有三种选项：
- subtree modifications：节点的子节点被增删时触发
- attributes modifications：节点的属性（class、style等）被修改时触发
- node removal：节点被移除时触发
触发后，DevTools会立刻停在执行栈里，你从Call Stack一眼就能看到是哪个函数动了这个节点。这招在排查“某个元素突然消失”“class莫名其妙被加回去”“定位样式被覆盖”这种问题时特别好使。比起你猜测、加日志、一遍遍刷新，它直接把你带到第一案发现场。
DOM断点的实现原理不复杂，浏览器在DOM结构变化时触发对应回调，DevTools将这次变化关联到触发它的JS调用栈。所以只要变化发生在JS运行期间，这个断点就能抓到。对于那种由浏览器原生行为（比如表单提交自动刷新页面）造成的变化，断点可能不会触发，这时候就要结合Network等其他面板去看。
4. Network抓包：把每一个请求的来龙去脉看穿
4.1 过滤、列自定义与请求重放
Network面板是所有网络请求的透明窗口。页面加载了多少资源、请求参数是什么、响应状态码如何、耗时多久，全都看得清清楚楚。
先说过滤。请求多的时候，纯靠滚动找目标等于大海捞针。顶部一排类型按钮可以按资源类型过滤：XHR、JS、CSS、Img、Media、Font、WS、Doc。其中日常调试接口时，点一下XHR基本就能把Ajax请求隔离出来。下面的过滤输入框更高级，支持语法过滤，比如：
-status-code:404 domain:api.example.com has:response-header:content-type这些语法组合起来，能在几千个请求当中快速锁定你关心的那几条。过滤框本身也可以通过Ctrl+F呼出，配合正则表达式使用更强大。
其次说说请求列表的列配置。右键表格头，可以勾选显示更多列，比如Method、Status、Type、Initiator、Size、Time、Waterfall。Initiator列尤其有用，它告诉你是哪个脚本发起的这个请求，对于查找“谁偷偷发了请求”这类问题，直接从Initiator跳到调用代码。
最后谈谈请求重放。右键一条请求，有两个高频选项：Copy → Copy as cURL / Copy as fetch，可以把请求转成命令行或脚本格式发给后端同事复现。还有一个“Edit and Resend”选项——直接在面板里修改请求头、请求体，重新发送，看不同参数下的响应差异。我调试接口时经常用它，改一个参数点重发，比在浏览器控制台手写fetch快得多。
需要注意的是，Network面板默认只会记录打开面板之后发生的请求，刷新前的都看不到。如果需要看页面加载全过程的请求，就先打开面板再刷新，必要时开启Preserve log，这样页面跳转或刷新后的旧日志也保留着。
4.2 弱网模拟与自定义网络条件
网络面板的另一个价值是模拟慢环境。顶部有个“Network throttling”下拉框，内置选项包括在线、快速3G、慢速3G以及离线。想测试弱网下页面的加载表现、接口超时重试逻辑、懒加载占位图是否正常，都可以直接选慢网络看效果。
更精细的需求可以选“自定义”并配置网络配置文件：设置更低的带宽、增加延迟。我做一个图片懒加载优化时，就专门用自定义网络配置成几十KB的带宽去验证占位图是否尽早展示，这个操作在生产环境几乎没法复现，但在DevTools里一键就能测。
另外Network面板的“禁用缓存”复选框值得养成随手勾上的习惯。调试前端样式和脚本时，最怕改了代码但浏览器用了旧缓存，勾上这个选项，再配合刷新，可以很大程度避开缓存干扰。移动端上线前测试也建议开启它，能模拟用户首次访问的真实加载。
提示：弱网模拟影响的是DevTools里打开的页面请求，并不会改动系统网络设置。所以测完记得把限速选项切回Online，不然事后调试时莫名其妙感觉所有请求都慢吞吞的。
4.3 Waterfall时间线：找出真正的瓶颈
每条请求右侧的Waterfall图表展示请求的完整生命周期。你能看到请求在各阶段的时间消耗：排队（Queued/Stalled）、DNS解析、TCP连接、SSL握手、发送请求（Request sent）、等待响应（TTFB）、内容下载（Content Download）。把鼠标悬停在阶段色块上，可以看到精确到毫秒的时间。
怎么读这个时间线？我总结了一套判断逻辑：
- 如果TTFB占比最大，说明服务器在你发出请求后很久才返回数据，问题很可能在后端接口、数据库查询、网关转发；
- 如果Content Download占比很大，说明资源体积过大，需要对图片、脚本、字体做体积优化；
- 如果大量请求长时间停留在Stalled/Queued，说明浏览器并发连接数受限，可能是同一域名下请求过多，要想想CDN资源分散。
单个请求的详情页里有五个子面板：Headers、Payload、Preview、Response、Timing。Headers用于查看请求头、响应头，响应头里的Cache-Control、ETag等缓存信息就是从这里读的。Payload可以看到请求参数，Preview和Response则是响应数据的两种展示方式，前者格式化更好读，后者是原文。
我在实际项目里还遇到过一类奇怪现象，接口明明返回200，但浏览器报跨域错误。这种情况要看Headers里是否存在Access-Control-Allow-Origin，再结合Status code是否为预检请求（OPTIONS）的204，基本就能判断是服务端没配置好CORS还是前端请求头不对。
5. Sources源码调试：断点才是真正的debug精髓
5.1 五种断点的适用场景
在Console里打日志只是被动观察，在Sources里下断点才是主动控制。断点让代码执行到指定位置时暂停，你在那一刻检查变量、作用域、调用栈，然后决定继续还是修改。
最常见的是行断点：在Sources面板打开源码文件，点击行号即可。适合你大概知道问题在哪一行的时候。比行断点更精准的是条件断点：在行号上右键，选择“添加条件断点”，输入一个表达式，只有表达式为真时才暂停。比如在一个循环里只想在第5次迭代时停，就写i === 5。这种方法极大减少了手动跳过前四次的烦躁。
Logpoint是一个我强烈推荐的功能。它本质上是“输出日志但不暂停”，右键行号选择“添加日志断点”，输入表达式，运行到这行时会往Console输出，而代码不会停下。这有什么用？在循环体、高频事件回调里，想观察某个变量变化但又不希望代码暂停，Logpoint比console.log更优雅，因为你不用改源代码，调试完删掉即可。它可以算是“临时统计探针”的完美实现。
事件断点则适合监听浏览器事件。在Sources面板右侧的Event Listener Breakpoints里，勾选需要中断的事件类型，当事件触发时浏览器会停在对应监听函数里。排查“点击没反应”“滚动事件异常触发多次”这类问题，提前勾选click或scroll事件，能直接定位到处理函数。
最后是异常断点。前面Console章节提过Pause on exceptions，这里再补充一个细节：它作为全局开关会中断所有异常，灵活性有限。Sources里可以为特定错误类型单独设置，比如只中断Caught exceptions，只中断未捕获异常，或者为具体的XHR/fetch失败设断点。这样在大型应用里不至于随便一个被捕获的异常就把你打断。
5.2 调用栈、作用域与监视器的联动分析
断点触发后，右侧三条关键信息面板进入工作状态：Call Stack、Scope和Watch。
Call Stack是调用链，一列排下来能看到当前函数是被谁调用的、上面那层又是由谁调用的。排查“这个函数到底被谁呼叫”时，不看Call Stack总是绕远路。Scope显示当前作用域的所有变量，包括局部变量、闭包变量、全局变量，这个面板里的变量值你可以直接双击修改，然后继续运行——非常利于“假设推理式”排查，比如把status字段改成1再看后续逻辑。
Watch监视器则用来持续跟踪指定的表达式。你可以添加this.name、document.title这样的表达式，每次断点停下来，Watch区域都会同步计算它的最新值。对于“同一个变量在多个断点间的变化过程”，Watch比手动展开Scope高效得多。
步进操作也有讲究。Step Over（F10）执行当前行但不进入函数内部，适合确认这一行整体没问题。Step Into（F11）会进入函数内部一行一行执行，适合深挖被调用函数的行为。Step Out（Shift+F11）则是从当前函数跳回上一层，适合你已经看完函数细节不再需要继续跟的情况。
我还常用Restart Frame功能，在Call Stack里右键当前栈帧，选择Restart frame，它会把当前函数的执行重新开始。这样你不需要刷新页面重新走一遍用户操作，直接在当前场景下重复执行函数，对验证修复效果特别有用。
5.3 Logpoint、脚本黑盒与Overrides组合技
Logpoint单独用很好，但配合“脚本黑盒”才能发挥最大价值。项目中引用了各种第三方库，断点往往停在这些库内部，Call Stack一大串，业务代码被淹没。右键代码文件，选择“忽略脚本”（或Add script to ignore list），被忽略的文件在单步执行时会直接跳过，调用栈里也不会显示它们的内部帧。这意味着你只关注自己写的业务逻辑，不被底层框架干扰。
Overrides是我处理线上问题的法宝。打开Sources面板的Overrides标签，选择本地目录作为覆盖目录，然后在Network里找到线上加载的JS或CSS文件，右键选“Overrides”并保存到本地。这样你在DevTools里改的就是线上文件，刷新后改动依然生效，因为浏览器优先加载本地覆盖文件而不是线上资源。这个机制适合调试生产环境问题：你改本地方案验证效果，确认后回到代码仓库里提交正式修复。
最后还得提一下Snippets。Sources面板左侧有Snippets标签，可以保存一段自定义JS脚本，随时运行。我常在里面存一些高频操作脚本，比如一键清空localStorage、自动填充表单、批量导出接口数据等。相比在Console里手敲长命令，Snippets保存后永远是自己的工具箱。
提示：Overrides虽然方便，但很容易让你误以为线上代码已经改了。每次用Overrides前看清楚文件来源，验证完立刻清理本地覆盖，避免下次调试时遇到莫名其妙的差异。
6. Performance与内存：把卡顿量化，让泄漏现形
6.1 Performance录制：从“感觉卡”到“知道多卡”
页面卡顿、滚动不流畅、动画掉帧，这种问题靠肉眼很难说清“到底卡在哪”。Performance面板能把运行过程变成可以量化的视频记录。
录制流程很简单：打开Performance，点击左上角录制按钮，然后在页面上执行要分析的操作，比如滚动、点击、播放动画，结束后停止即可。也有一键记录页面加载的Reload功能。录制完成后面板会展示一段河流图，包含FPS、CPU、网络、内存四档状态，时间轴与主线程任务一一对应。
怎么快速看结果？我一般先看FPS这行，如果出现大片红色和低数值，说明这段时间确实掉帧严重。接着看CPU占用，如果长时间保持在90%以上，基本可以断定存在密集计算。然后切到Main线程部分，火焰图上的每个色块代表一个任务，块越高越大说明这个操作越耗时。点击某个任务块，面板底部会展示它的代码位置和当前栈，顺着就能找到瓶颈函数。
这里要特别提一下Long tasks。浏览器主线程被一个超过50毫秒的任务占用时，用户在页面上会感到明显的响应延迟。Performance录制结果里的红色三角标记就是长任务，点开后能看到时长和所属调用栈。优化思路很简单：把长任务拆碎，用requestIdleCallback、setTimeout分片，或者把计算挪到Worker线程。
6.2 长任务与函数级耗时定位
定位到主线程的某个色块后，右侧还有三种分析视图：Bottom-Up、Call Tree和Event Log。Call Tree适合看某个动作的整体调用链条，从根看到叶；Bottom-Up适合按自耗时间排序，找出最耗时的具体函数；Event Log则按时间顺序列出所有浏览器事件，适合确认某操作到底触发了哪些事件。
组合使用：先用Event Log确认“用户点击之后发生了什么事件”，再用Call Tree缩小到某个任务，最后用Bottom-Up找到那个函数。这种从大到小的排查路径，能避免在几千条任务记录里迷失方向。实际操作中，我会先在Main线程上找色块特别高耸的任务，然后点击它，跳到Call Tree的对应位置，再打开Bottom-Up排序看它的子调用是否集中。
有同学会问，为什么在Sources里加日志不好？日志能告诉你函数被调用了，但频率一高，打印日志本身也会占性能。Performance录制的优势是不需要侵入代码，直接从浏览器内核层面记录执行细节。所以遇到“卡顿”先录一段再说，比对着源码一行行猜靠谱得多。
6.3 Heap快照：揪出内存泄漏的幕后黑手
内存问题比性能卡顿更难感知，它往往是缓慢恶化的。页面用时间长了越来越卡、Tab占比越来越大，基本就是内存泄漏的征兆。DevTools的Memory面板提供三种记录方式：Heap snapshot、Allocation instrumentation on timeline和Allocation sampling。
Heap snapshot是当前时刻的堆内存快照，包含所有对象、字符串、闭包、DOM节点等信息。排查泄漏的标准操作是拍三张快照：一开始拍一张，做一些可能触发泄漏的操作后拍第二张，过一段时间再拍第三张。重点对比第二张和第一张，以及第三张和第二张之间的差异。如果某个对象数量持续增加不回落，就非常可疑。
常见泄漏源头我列几个：全局变量缓存了不该缓存的数据；setInterval或者setTimeout没有及时清理；事件监听器绑了但没解绑，尤其挂在window、document这些全局对象上的；闭包不小心持有大量DOM引用；还有上拉加载列表时旧数据没有被正确丢弃。
在Allocation instrumentation on timeline里，你可以按时间顺序看到被分配的对象。执行某个操作后，选中有明显分配标记的时间段，底部表格会显示这段时间分配的内存类型和来源函数。配合几次重复操作，泄漏点很快就现原形。这个面板比Heap Snapshot更直观，缺点是录制本身有一定开销，不适合在生产环境长期开。
7. 移动端调试：不只是切个手机尺寸
7.1 Device Mode模拟的局限与要点
DevTools里的设备模拟（Device Mode）很多人第一反应就是“选个手机型号看布局”，但其实它能做的事远不止这些。Ctrl+Shift+M进去后，你可以设置分辨率、DPR（设备像素比）、用户代理、触摸事件、网络限速，甚至模拟加速度传感器。
我平时用Device Mode最重要的场合是验证响应式断点，以及排查“为什么手机上看不了桌面版效果”。把Devices切换成某个常见手机型号，页面会按对应viewport渲染，你的媒体查询是否生效一目了然。触摸模拟也很有用，比如某些PC端点击事件在移动端触摸事件里行为不同，勾选触摸模拟后能提前暴露问题。
但Device Mode毕竟是在桌面浏览器里模拟，和真实手机有几处本质差异：第一，真机上的字体渲染、系统设置、浏览器默认样式不尽相同；第二，真机的GPU、内存、网络状况会暴露性能瓶颈，桌面模拟测不出真实帧率；第三，移动端特有的WebView环境、证书问题、跳转逻辑，DevTools模拟不了。所以模拟只能当第一道筛子，最终一定要走真机调试。
注意移动端浏览器对某些Web API的支持和电脑端不完全一致。我遇到过有些调用剪贴板、振动、通讯录的代码在Device Mode下没反应，一度以为是代码问题，后来拿到真机上一跑，却发现顺畅无比。所以别把模拟结果当作最终结论。
7.2 真机远程调试实操流程
真机调试才是移动端开发的最终归宿。Android设备配Chrome或Edge都有成熟的远程调试方案。基本流程是：手机开启开发者选项和USB调试，用数据线连到电脑，手机上打开要调试的页面，电脑端访问chrome://inspect（如果用的是Edge就是edge://inspect），就能看到设备列表和已打开的页面。点击“inspect”按钮，会弹出一个和桌面端完全一样的DevTools窗口，Console、Network、Sources、Performance全部可用。
关键点有三个：一是手机上必须开启USB调试，不同品牌系统的菜单位置不一样，有的还需要额外步骤或授权弹窗；二是手机和电脑要能正常识别设备，第一次连接时手机上会弹出“允许USB调试”的确认框，别手滑点了拒绝；三是确保能访问到你要调试的页面，具体如何打通网络链路根据各人项目需求来定。
iOS端的真机调试走另一套方案，通常用Safari开发菜单配合Web Inspector，前提是设备与系统版本匹配，过程相对繁琐。这里不展开太多，只想提醒一点：移动端调试方案的差异本质在于浏览器内核和协议不同，别拿Android的流程硬套iOS，先确认再用。
真机调试最常用的场景有几个：线上投诉“安卓机白屏”，先连上真机在Console看报错；某个接口在移动网络下返回慢，用Network看瀑布流；真机上滚动比桌面卡，用Performance录一段验证。只有真机的真实环境才能把这些问题的复现概率拉满。
提示：真机调试时把电脑和手机保持在同一个局域网有时会省去不少麻烦，但跨设备调试的日志传输走的是调试协议，不依赖你在DevTools里手动改什么，通常配对成功即可直接使用。
8. 调试中的经典翻车现场与排查路径
8.1 “明明改了却没生效”的几种真相
“我改了样式它没变”“我改了接口逻辑刷新后还是旧行为”，这类问题的根源通常是缓存或构建流程，而不是代码本身写错。我遇到过的场景大致有这几种：
第一种是浏览器缓存。HTTP强缓存一旦命中，浏览器直接用本地资源，不向服务器发请求。刷新页面前按Ctrl+Shift+R硬刷新，或者在Network里勾选禁用缓存再刷新，能排除这个因素。记得验证完把条件还原，别影响正常业务测试。
第二种是构建产物未更新。我改的是src目录下的源码，但线上或本地运行的是打包后的dist，如果构建进程没重新跑，自然没生效。这时去Sources面板里用Ctrl+P打开对应文件，确认内容确是你改过的版本，如果内容还是旧的，说明构建没跟上。
第三种是样式优先级问题。若干条CSS都作用于同一个元素，最终生效的是权重最高的，而不是你最后写的那条。你新增了属性却看不到效果，先打开Computed看最终计算值，再顺藤摸瓜看它来自哪个规则。在DevTools里调试时能看到所有匹配的规则及其优先级，这个参考价值远超回到编辑器里瞪眼。
最后还有一类隐藏的坑：改的变量名被混淆了。压缩后代码变量名变成a、b、c、d，你在DevTools里打开的是源码通过Source Map映射出来的文件，这种场景比较多见于线上疑难问题，需要结合Source Map条件断点和Overrides配合排查。
8.2 断点不生效、日志不输出的排查顺序
如果下了断点却根本没停，我建议按这个顺序排查：
- 先在Sources面板里确认你打开的文件确实是当前浏览器正在运行的文件，而不是另一个同名文件。用Ctrl+P打开文件时注意路径是否和Network面板中的URL一致。
- 检查文件是否有Source Map映射。如果源码和运行代码之间有映射，断点通常会落在源码上；没有映射就只能对压缩代码打断点，或者在压缩代码里先找线索。
- 确认该脚本是否被加入了“忽略列表”。被忽略的脚本断点不会触发，需要去设置里移除。
- 确认浏览器没有在无痕模式下禁用某些DevTools能力。有的环境里Pause on exceptions和部分断点类型在普通页面正常，但无痕窗口或特定扩展环境下行为不同。
- 最后看Console里有没有报错。如果脚本在运行中断抛了异常并且被捕获，你的普通断点可能根本没机会执行到，先处理异常。
日志不输出则分两种情况：一是console.log被构建工具剥离了，这在生产构建里很常见，得看构建配置；二是输出位置不在当前选中的上下文。Console顶部有当前执行上下文下拉框，不同iframe或Worker环境里的日志会在不同上下文下显示，切换上下文再查一遍往往能发现漏网之鱼。
8.3 一些我沉淀下来的调试习惯
文章最后分享几个我长期坚持的操作习惯，它们让我个人排查问题的速度提升非常明显。
第一，遇到问题先界定边界，再开面板。界面样式问题先去Elements，接口数据问题先去Network，性能卡顿先去Performance，逻辑不对先去Sources。不按这个规则来，上来就在Console和Network之间反复跳，很容易浪费时间。
第二，把可复用的调试脚本全部沉淀为Snippets。我在浏览器书签里几乎不放调试技巧，但在Sources的Snippets里存了一堆自己的工具函数和操作片段，遇到类似场景直接运行，省去重复造轮子。
第三，线上问题优先考虑Overrides和Logpoint，而不是直接在公共网络环境里改代码验证。用覆盖文件加日志输出，尽可能在不污染生产代码的前提下完成验证，确认后再去仓库改正式代码。
第四，多利用条件断点和Logpoint，少用无脑console.log。日志一旦多起来，自己的筛选成本也很高，还容易影响到同事在共享环境里的排查。
我个人在实际操作中的体会是：DevTools这套工具从诞生到现在已经迭代了很多版本，但核心的调试哲学一直没变，那就是把不可见的运行时变成可见的、可暂停的、可回放的。学会这个工具，本质上学会的不是操作顺序，而是建立一套“现象 → 假设 → 验证”的问题处理循环。顺着这个思路练习，很快就能把前面这些技巧内化成自己的习惯。
