想快速定位Bug先学习一下F12抓包吧。这句话我反复对团队里的新人讲因为这些年做过的大小前端项目里真正让人心力交瘁的从来不是写代码而是猜Bug。页面白屏了到底是接口没返回还是前端渲染崩了接口报400了到底是参数传错还是后端解析不了线上环境偶发故障本地又复现不出来双方对着代码干瞪眼。这种时候如果只会说“我觉得是前端/后端的问题”排错效率基本靠运气。而F12抓包就是把运气变成确定性的第一步。抓包这个词听起来有点黑客味实际上就是用浏览器内置的开发者工具DevTools去观察页面发起的每一个网络请求。它能直接回答三个关键问题请求发出去了没有、请求带的数据对不对、服务器回的数据是什么。三个问题有了答案绝大多数Bug的定位范围就会从“整个系统”缩小到“某一段代码”或者“某一个配置”。无论你是刚入门的前端新人还是被联调折磨已久的老手这份围绕F12抓包拆开的实操手册都能让你在排错的时候少走弯路。我会按这套思路往下讲先搞懂抓包的对象是什么再把Network面板的每一项操作拆开细讲然后是实际定位Bug的分析路径最后是进阶技巧和常见问题实录。都是上手就能用的东西。1. 先想明白抓包抓的到底是什么1.1 一次网络请求的完整链条把一次接口请求想象成寄快递就很好理解了。前端页面是寄件人后端服务是收件人请求就是一件包裹。包裹正面的地址信息是URL里面装的货是请求参数快递员经过的每一个站点是网络链路收件人签收后返给你的底单就是响应数据。抓包干的事情就是站在中转站把每一件包裹的标签、箱内物品、在途时间和签收底单全部拆开检查一遍。这样一看很多Bug的本质就清楚了不是代码逻辑有多复杂而是包裹压根没寄出去、寄错了地址或者装箱单和后端要求的对不上。比如按钮点了一下前端以为请求发出去了实际上事件监听没绑上再比如请求是发了但参数名拼错了一个字母后端收到包裹却拆不出能用的东西。这些问题只盯着代码看很容易绕进死胡同但在Network面板里真相往往就摆在那里一眼就能看出来。1.2 DevTools面板分工抓包只是其中一环F12打开的不是只有一个Network面板而是一整套开发工具。排错之前最好先对各个面板的分工有个整体印象这样才不会在错误的面板里浪费时间。Elements负责页面结构和样式定位布局错乱、样式没生效的问题用它。Console日志和报错信息都在这里前端代码运行时报错会第一时间出现在这里。Sources代码调试面板支持断点、单步执行、查看调用栈适合精细排查逻辑问题。Network网络请求面板也就是抓包的核心区域所有请求的来龙去脉都在这里。Application存放Cookie、LocalStorage、SessionStorage、IndexedDB等浏览器存储数据。Performance录制和分析页面性能定位加载慢、渲染卡顿的问题。这六个面板对应的是不同层面的问题。遇到一个Bug先想清楚它最可能出现在哪个层面页面长什么样是Elements的事代码报不报错是Console和Sources的事数据来没来则是Network的事。而数据来没来几乎永远是前后端联调时第一个要确认的环节所以Network面板往往就是排错的第一站。1.3 哪些场景应该第一时间用抓包不是所有Bug都要靠网络面板排查。比如一个按钮点击后颜色没变那是状态管理或者CSS的问题去Sources打断点更直接。真正适合抓包的场景通常都和数据交互强相关。我总结了下面三类第一类是页面白屏或部分内容缺失。这时候核心疑问就是数据有没有回来。Network里能看到200响应、数据结构正常那就是前端渲染逻辑出了问题如果接口404了那就先修接口地址别在前端代码里找半天。第二类是接口报错或超时。需要区分是前端传参问题、后端逻辑问题还是网络链路问题。通过请求详情里的Payload、Headers和状态码往往几秒钟就能明确方向。第三类是本地正常但线上异常。这种环境差异带来的Bug最让人头疼而抓包可以对比两个环境下请求地址、请求头、Cookie、响应内容之间的差异差异点往往就是问题点。这三个场景的共同点在于问题的表象都在页面上但真正的原因藏在请求链路里。没有一份完整的抓包记录排错就只能靠猜有了它排错就从“侦探推理”变成了“按图索骥”。2. Network面板核心实操把一次请求彻底看穿2.1 请求列表怎么读才高效打开DevTools切到Network按F5刷新页面列表里会跳出各种类型的请求。初次接触的人很容易被一堆英文术语吓住其实把字段翻译成大白话就几个问题这条请求成功了吗、请求的是什么资源、数据有多大、花了几毫秒。Name列是请求名称显示的是接口路径或静态文件名Status列是状态码直接反映请求结果Type列表示资源类型接口请求一般是fetch或xhrSize列是响应大小如果显示from disk cache或from memory cache说明走的是浏览器缓存文件可能不是最新的Time列是消耗时间接口慢不慢先看这个数字。右侧还有一个Waterfall瀑布图用色块分段展示每个请求的耗时构成一眼就能挑出加载最慢的资源。实际操作中我每次打开Network面板都会先做三个固定动作一是勾选Preserve log这样页面跳转后请求日志不会被清空二是调试时打开Disable cache避免缓存干扰验证结果三是调整列表显示的列——右键点击表头可以勾选Protocol、Connection ID、Remote Address等隐藏列排查复杂网络问题时这些信息很关键。新手经常犯的一个错误是不看Type列结果在一堆图片、脚本、字体的请求里翻半天找不到接口。记住一条规则接口请求的Type通常是fetch或xhr直接点工具栏上的Fetch/XHR过滤按钮列表里剩下的就是你要盯着的对象。2.2 点击请求后右侧四块区域怎么看在请求列表里点开任意一条请求右侧会展开详情区域。真正排错的时候大部分线索都藏在这里面。Headers这个Tab信息量最大。先看General部分它会告诉你请求方式、完整URL、最终状态码。然后是Request Headers重点看Content-Type、Authorization、Cookie这几个和业务强相关的字段。最后是Query String Parameters和Payload区域展示前端实际发出去的数据。我在实际联调中遇到“后端收不到参数”的情况问题大多就是这几类Content-Type填错了比如该用application/json却用了form表单格式参数名拼写不一致或者参数被放在URL的Query上而后端只从请求体里取值。Payload这个Tab是区分问题归属的核心依据。养成一个习惯每次接口联调发起请求后先点开Payload把里面的字段和接口文档逐项对照。只要字段名、类型、层级关系一致前端这边基本可以撇清责任一旦发现不一致问题就摆在眼前了。一次印象很深的排查里前端传的是order_id后端要求的是orderId两边代码看起来都“没错”数据库里就是查不到记录最后就是在这个Tab里一眼发现的差异。Preview会把响应体格式化渲染返回的JSON会变成一棵可展开的树看数据结构、字段层级、具体值都很方便。Response则展示原始响应文本当Preview渲染异常或者需要确认响应里的特殊字符时切到Raw模式看原始数据最准确。Timing把一次请求的生命周期拆成了几个阶段排队、DNS解析、连接、发送、等待响应、接收数据。接口慢的时候这个Tab能告诉你瓶颈在网络链路还是后端处理。Waiting等待响应时间特别长多半是后端处理慢Content Download时间异常要考虑响应体是不是太大是不是该做压缩或者分页。2.3 过滤、搜索和保存别在请求堆里迷失页面越复杂Network里的请求就越多动辄上百条都是常态。这时掌握过滤和搜索就是保命技能。过滤最简单的操作是点工具栏的Fetch/XHR按钮只看接口请求。再配合过滤框输入关键字请求列表会实时筛掉不匹配的项。全局搜索则更进一步在列表焦点下按Cmd/CtrlF可以输入URL关键字、请求头内容甚至响应体里的字符串来查找。有一次线上接口返回了一个特定业务码我直接拿业务码搜索马上定位到是哪个接口返回的省得逐条翻找。保存也有讲究。遇到需要和后端或测试同事沟通的Bug我会先把Network里的相关请求导出为HAR文件就是列表左上角的下载图标。HAR文件记录了一整批请求的完整信息包含URL、请求头、请求体、响应内容、耗时。把文件发给同事对方导入自己的DevTools或其他排查工具就能看到和你的现场一模一样的请求情况。这个做法比截图传话可靠得多因为截图上没有的信息HAR里全都保留了。3. 从抓包结果反推Bug根源一套可复用的判断思路3.1 状态码是排错的方向盘拿到请求结果第一步永远是看状态码。状态码直接告诉你本次请求在HTTP层面的结果我把它当作排错的方向盘。先强调一个容易踩的坑200不代表万事大吉。很多接口就算业务失败HTTP状态码也返回200只在响应体里放一个非0的code字段来标识。所以看到200还要顺手在Preview里确认业务码和数据是否正常。301/302属于重定向页面跳转异常的时候沿着重定向路径看它到底跳到了哪里可能就会发现URL被拼错或者被代理规则带偏。304表示协商缓存生效浏览器直接用了本地缓存。如果你改了后端逻辑但前端页面不更新第一步就应该怀疑是不是它。401和403都和权限相关401一般是没登录或登录态过期403是登录了但没有权限。排查时去请求头里看Authorization和Cookie再配合Application面板看当前存储的数据是不是Token丢了、Cookie过期了一目了然。404说明接口地址对不上号优先排查URL拼写、路由是否存在以及当前环境是不是错了——我见过测试页面把请求打到生产域名的情况接口自然是404。五开头的状态码比如500、502、503基本指明后端或网关出了问题。这时候把请求详情里的响应信息、请求头、请求体完整截给后端远比丢一句“你接口挂了”更有价值。3.2 现场分锅一次400排查的完整复盘拿一个真实项目里反复出现的场景复盘。列表页点击查询后页面弹“系统错误”后端群里问“是不是前端传参错了”前端群里回“我这边请求正常”两边来回拉扯十分钟没有任何进展。而用抓包数据这个问题本可以在半分钟内定论。打开Network找到那个失败的请求状态码400。点开Headers看到Request Headers里Content-Type是application/jsonPayload传参是order_id12345参数名与接口文档完全一致。再往下看响应体后端返回了一段校验错误写的是orderId不能为空。问题一下子就清楚了前后端字段命名不一致一个传的是order_id一个接的是orderId后端解析不到字段自然报校验失败。这种情况下最优解是前后端约定一份统一的接口字段规范所有接口的参数命名、类型、层级都按文档走。抓包在这里起到的作用就是把原本说不清谁对谁错的场面变成一条有据可查的线索。如果前端和后端都查了代码觉得没问题我还有一个对比动作把请求复制成cURL在命令行里直接执行。同样一条请求在命令行里能通浏览器里却报错说明浏览器环境下多携带了某些Cookie或请求头引起冲突命令行里也复现同样的错误那就是代码本身发出去的数据有问题。这个对比能把“环境问题”和“代码问题”快速切分开。3.3 配合Console与Sources把网络请求和代码行为连起来抓包能回答“请求长什么样”但“代码为什么走到了这一步”还需要靠Console和Sources面板。Console里看到红色报错先分清错误类型。SyntaxError说明代码语法写错了括号、引号之类的问题直接跳到对应的行修TypeError最常见的是读取了不存在对象的属性——比如接口返回的数据里没有你期望的某个字段代码还继续在这个字段下面取属性立刻就崩了。看清报错信息里的文件路径和行号点击就能跳到Sources里的对应位置。Sources面板的核心操作是断点。在可能出问题的代码行上加断点重新触发场景代码会停在断点上然后你可以单步执行观察变量的值、请求参数是在哪个环节被修改的。我习惯把Sources和Network配合起来用先确认请求发出前的参数是不是符合预期如果不符合就在数据构建处打断点通常一两步就能找到是哪行代码把参数改坏了。还有一种情况是产品逻辑本身没问题代码和接口都正常但页面显示的却是旧数据。如果在Network里看到from disk cache在Console里输出的值也是旧的就别再怀疑代码没生效了去排查缓存策略和资源版本号。4. 进阶抓包技巧模拟网络、复制现场与重放请求4.1 模拟弱网和断网复现环境型Bug有一类Bug很折磨人平时一切正常一进电梯、一过隧道、网络稍微一卡就出问题。这种Bug在良好的开发环境下根本复现不了好在DevTools内置了网络状态模拟功能。Network面板顶部有一个网络状态选择框默认是No throttling。切换成Fast 3G或Slow 3G后刷新页面加载过程会被明显降速这时候哪些资源加载失败、接口有没有超时、页面有没有做好加载占位都会比正常网络下更显眼。还有一个Offline选项直接模拟完全断网用来测试前端有没有做异常兜底。我曾在移动端项目里发现断网时页面抛出一堆未处理的Promise错误用户看到的却是静默失败没有任何提示就是靠Offline模式复现之后才修好的。如果你需要更精确的网络参数可以添加自定义配置手动设置下载速度、上传速度和延迟。模拟线上弱网环境时建议根据线上监控平台统计的真实网络指标来填参数而不是凭感觉填一个值。4.2 复制为cURL把完整现场交给队友定位接口Bug沟通成本往往比查找成本还高。与其截图加上大段文字描述不如直接把请求转成一条curl命令发给对方。在Network请求列表中右键点击某条请求选择Copy再选Copy as cURLDevTools会生成一条完整的命令行请求包含URL、请求方法、全部请求头、Cookie和请求体。后端同事拿到这条命令不需要登录系统、不需要翻接口文档、不需要猜测复现路径在终端粘贴执行就能看到同样的响应结果。一次线上事故排查里我就是靠这种方式快速让后端锁定了问题范围省掉了前后端反复确认信息的时间。这里要提醒一句cURL里通常包含Cookie等敏感信息在工单系统或者公共群聊里分享时先把敏感字段删掉避免泄露登录态。尤其对接外部团队的时候这个动作能防止不少麻烦。4.3 重放和改造请求做边界测试在Network列表里选中一条请求右键点击Replay XHR就能在不重新操作页面的情况下再发一次同样的请求。这个功能在验证接口稳定性的时候特别好用连续重放同一个请求十几次观察有没有偶发的超时、报错和数据异常。偶发问题用这个方式排查比自己一遍遍点页面高效得多。更实用的玩法是改造请求再发。复制成cURL之后可以在命令行里任意修改Payload、URL和请求头。比如把一个必填参数删掉看后端会不会返回友好提示把字段改成超长字符串、特殊字符、负数、极小的数值观察后端是否有边界校验把请求方法改一下看看接口有没有因为方法使用不当而产生隐患。这类边界测试放在联调之前自己做一遍能规避掉大量上线之后才暴露的稳定性问题。移动端调试也有对应的抓包补充方案。很多真机浏览器支持远程调试手机连上电脑打开浏览器调试模式就能在电脑的DevTools里看到手机页面的Network请求。真机的网络环境、Cookie、UA和模拟器差异很大排查“只在手机上出现”的Bug时这种方式几乎是唯一靠谱的路径。5. 常见问题与排查技巧实录5.1 打开Network却看不到任何请求这是一个高频问题。很多人问我明明页面有接口请求为什么Network面板一片空白原因通常不是工具坏了而是设置在捣乱。最常见的是没有勾选Preserve log。页面一旦发生跳转或者刷新默认情况下之前的请求记录会被清空。尤其有些页面打开瞬间就自动跳转等切到Network面板旧请求早就被清掉了。解决办法是提前勾上Preserve log再重新打开页面触发一次。第二种情况是请求被浏览器插件拦截。部分插件会按规则过滤广告域名或特定接口导致请求没有正常发出。排查方法也很简单临时禁用所有浏览器插件后再试基本能确认是不是插件在捣乱。还有一种是搜索条件或者过滤条件残留了。过滤框里留着之前的关键字或者误触了某些过滤按钮都会让请求列表看起来空空如也。先把过滤条件和搜索框清空再判断问题是否真的存在。5.2 请求一直Pending下不来Pending表示请求已经发出去了但始终没有收到完成信号。这种情况我一般按三条线路排查。第一后端处理慢。接口内部可能有长时间的循环、数据库锁等待或者依赖外部服务导致迟迟不返回。验证方法很直接用接口调试工具直接请求同一个URL如果同样长时间无响应基本可以锁定后端。第二请求体传输问题。Payload特别大或者多文件上传场景请求容易长时间挂起。这时看一眼Size列如果数值异常大就要考虑改成流式传输或确认服务端的接收限制。第三前端自身的问题。比如全局请求拦截器做了不合理的处理或者某段代码卡住了请求发出后的后续逻辑。用排除法逐个环节排查一般都能找到答案。5.3 改了代码不生效多半是缓存这是一个迷惑性很强的问题。代码改了、部署了但用户反馈线上还是旧版本。打开Network大概率能看到静态资源返回304或者Size列显示from disk cache。浏览器认为文件没变直接用了本地缓存。现代构建工具通常会给静态资源文件名加上内容哈希文件名变了缓存自然失效。如果你发现部署后哈希没变要检查构建配置是不是关闭了哈希命名或者服务端有没有错误地剥离版本参数。调试阶段可以用一个临时手段在DevTools里勾选Disable cache然后在开着DevTools的状态下刷新页面强制绕过缓存验证最新代码。但要清楚这个设置只在面板打开期间有效关掉之后缓存策略恢复正常不影响正常用户。5.4 跨域报错集中排查跨域报错在Console里通常显示为类似“has been blocked by CORS policy”的红色消息。原因大多是后端响应头缺失或者配置得不对。在Network里找到被拦截的请求切到Headers看响应头里有没有Access-Control-Allow-Origin。没有这个头后端需要处理跨域配置有但值不对比如写死了某个域名而后端又需要支持多个来源就要调整匹配规则。如果请求需要携带Cookie还要确认Access-Control-Allow-Credentials是否配置正确并且Allow-Origin不能使用通配符。还有一个容易忽略的细节预检请求。某些跨域请求会先发一个OPTIONS请求预检通过之后才会发出真正的业务请求。如果在Network列表里看到OPTIONS请求报错那么主请求自然被浏览器拦掉了。排查跨域问题的时候把OPTIONS请求也纳入观察范围很多“业务请求为什么没发出”的疑问就迎刃而解了。我从过去这些项目经历里最深的一点体会是会不会用F12抓包直接决定了你在团队里是那个“解决问题的人”还是那个“等着别人解决问题的人”。排错能力不是靠聪明堆出来的就是在这一次次打开Network、看Payload、查状态码、对比响应内容的动作里练出来的。最后再分享一个个人习惯我现在遇到前端任何异常都会先按F12让Console和Network先开口说话只有它们排除了网络层和运行时报错我才会去Sources里逐行追逻辑。这套固定动作帮我省下了大量逐行读代码的时间也帮我少背了很多不该背的锅。希望这个习惯对你同样有用。 
长河君 · 2026/10/18 5:28:51 · 阅读 1.2k F12抓包实战：从Network面板到前端Bug快速定位
想快速定位Bug先学习一下F12抓包吧。这句话我反复对团队里的新人讲因为这些年做过的大小前端项目里真正让人心力交瘁的从来不是写代码而是猜Bug。页面白屏了到底是接口没返回还是前端渲染崩了接口报400了到底是参数传错还是后端解析不了线上环境偶发故障本地又复现不出来双方对着代码干瞪眼。这种时候如果只会说“我觉得是前端/后端的问题”排错效率基本靠运气。而F12抓包就是把运气变成确定性的第一步。抓包这个词听起来有点黑客味实际上就是用浏览器内置的开发者工具DevTools去观察页面发起的每一个网络请求。它能直接回答三个关键问题请求发出去了没有、请求带的数据对不对、服务器回的数据是什么。三个问题有了答案绝大多数Bug的定位范围就会从“整个系统”缩小到“某一段代码”或者“某一个配置”。无论你是刚入门的前端新人还是被联调折磨已久的老手这份围绕F12抓包拆开的实操手册都能让你在排错的时候少走弯路。我会按这套思路往下讲先搞懂抓包的对象是什么再把Network面板的每一项操作拆开细讲然后是实际定位Bug的分析路径最后是进阶技巧和常见问题实录。都是上手就能用的东西。1. 先想明白抓包抓的到底是什么1.1 一次网络请求的完整链条把一次接口请求想象成寄快递就很好理解了。前端页面是寄件人后端服务是收件人请求就是一件包裹。包裹正面的地址信息是URL里面装的货是请求参数快递员经过的每一个站点是网络链路收件人签收后返给你的底单就是响应数据。抓包干的事情就是站在中转站把每一件包裹的标签、箱内物品、在途时间和签收底单全部拆开检查一遍。这样一看很多Bug的本质就清楚了不是代码逻辑有多复杂而是包裹压根没寄出去、寄错了地址或者装箱单和后端要求的对不上。比如按钮点了一下前端以为请求发出去了实际上事件监听没绑上再比如请求是发了但参数名拼错了一个字母后端收到包裹却拆不出能用的东西。这些问题只盯着代码看很容易绕进死胡同但在Network面板里真相往往就摆在那里一眼就能看出来。1.2 DevTools面板分工抓包只是其中一环F12打开的不是只有一个Network面板而是一整套开发工具。排错之前最好先对各个面板的分工有个整体印象这样才不会在错误的面板里浪费时间。Elements负责页面结构和样式定位布局错乱、样式没生效的问题用它。Console日志和报错信息都在这里前端代码运行时报错会第一时间出现在这里。Sources代码调试面板支持断点、单步执行、查看调用栈适合精细排查逻辑问题。Network网络请求面板也就是抓包的核心区域所有请求的来龙去脉都在这里。Application存放Cookie、LocalStorage、SessionStorage、IndexedDB等浏览器存储数据。Performance录制和分析页面性能定位加载慢、渲染卡顿的问题。这六个面板对应的是不同层面的问题。遇到一个Bug先想清楚它最可能出现在哪个层面页面长什么样是Elements的事代码报不报错是Console和Sources的事数据来没来则是Network的事。而数据来没来几乎永远是前后端联调时第一个要确认的环节所以Network面板往往就是排错的第一站。1.3 哪些场景应该第一时间用抓包不是所有Bug都要靠网络面板排查。比如一个按钮点击后颜色没变那是状态管理或者CSS的问题去Sources打断点更直接。真正适合抓包的场景通常都和数据交互强相关。我总结了下面三类第一类是页面白屏或部分内容缺失。这时候核心疑问就是数据有没有回来。Network里能看到200响应、数据结构正常那就是前端渲染逻辑出了问题如果接口404了那就先修接口地址别在前端代码里找半天。第二类是接口报错或超时。需要区分是前端传参问题、后端逻辑问题还是网络链路问题。通过请求详情里的Payload、Headers和状态码往往几秒钟就能明确方向。第三类是本地正常但线上异常。这种环境差异带来的Bug最让人头疼而抓包可以对比两个环境下请求地址、请求头、Cookie、响应内容之间的差异差异点往往就是问题点。这三个场景的共同点在于问题的表象都在页面上但真正的原因藏在请求链路里。没有一份完整的抓包记录排错就只能靠猜有了它排错就从“侦探推理”变成了“按图索骥”。2. Network面板核心实操把一次请求彻底看穿2.1 请求列表怎么读才高效打开DevTools切到Network按F5刷新页面列表里会跳出各种类型的请求。初次接触的人很容易被一堆英文术语吓住其实把字段翻译成大白话就几个问题这条请求成功了吗、请求的是什么资源、数据有多大、花了几毫秒。Name列是请求名称显示的是接口路径或静态文件名Status列是状态码直接反映请求结果Type列表示资源类型接口请求一般是fetch或xhrSize列是响应大小如果显示from disk cache或from memory cache说明走的是浏览器缓存文件可能不是最新的Time列是消耗时间接口慢不慢先看这个数字。右侧还有一个Waterfall瀑布图用色块分段展示每个请求的耗时构成一眼就能挑出加载最慢的资源。实际操作中我每次打开Network面板都会先做三个固定动作一是勾选Preserve log这样页面跳转后请求日志不会被清空二是调试时打开Disable cache避免缓存干扰验证结果三是调整列表显示的列——右键点击表头可以勾选Protocol、Connection ID、Remote Address等隐藏列排查复杂网络问题时这些信息很关键。新手经常犯的一个错误是不看Type列结果在一堆图片、脚本、字体的请求里翻半天找不到接口。记住一条规则接口请求的Type通常是fetch或xhr直接点工具栏上的Fetch/XHR过滤按钮列表里剩下的就是你要盯着的对象。2.2 点击请求后右侧四块区域怎么看在请求列表里点开任意一条请求右侧会展开详情区域。真正排错的时候大部分线索都藏在这里面。Headers这个Tab信息量最大。先看General部分它会告诉你请求方式、完整URL、最终状态码。然后是Request Headers重点看Content-Type、Authorization、Cookie这几个和业务强相关的字段。最后是Query String Parameters和Payload区域展示前端实际发出去的数据。我在实际联调中遇到“后端收不到参数”的情况问题大多就是这几类Content-Type填错了比如该用application/json却用了form表单格式参数名拼写不一致或者参数被放在URL的Query上而后端只从请求体里取值。Payload这个Tab是区分问题归属的核心依据。养成一个习惯每次接口联调发起请求后先点开Payload把里面的字段和接口文档逐项对照。只要字段名、类型、层级关系一致前端这边基本可以撇清责任一旦发现不一致问题就摆在眼前了。一次印象很深的排查里前端传的是order_id后端要求的是orderId两边代码看起来都“没错”数据库里就是查不到记录最后就是在这个Tab里一眼发现的差异。Preview会把响应体格式化渲染返回的JSON会变成一棵可展开的树看数据结构、字段层级、具体值都很方便。Response则展示原始响应文本当Preview渲染异常或者需要确认响应里的特殊字符时切到Raw模式看原始数据最准确。Timing把一次请求的生命周期拆成了几个阶段排队、DNS解析、连接、发送、等待响应、接收数据。接口慢的时候这个Tab能告诉你瓶颈在网络链路还是后端处理。Waiting等待响应时间特别长多半是后端处理慢Content Download时间异常要考虑响应体是不是太大是不是该做压缩或者分页。2.3 过滤、搜索和保存别在请求堆里迷失页面越复杂Network里的请求就越多动辄上百条都是常态。这时掌握过滤和搜索就是保命技能。过滤最简单的操作是点工具栏的Fetch/XHR按钮只看接口请求。再配合过滤框输入关键字请求列表会实时筛掉不匹配的项。全局搜索则更进一步在列表焦点下按Cmd/CtrlF可以输入URL关键字、请求头内容甚至响应体里的字符串来查找。有一次线上接口返回了一个特定业务码我直接拿业务码搜索马上定位到是哪个接口返回的省得逐条翻找。保存也有讲究。遇到需要和后端或测试同事沟通的Bug我会先把Network里的相关请求导出为HAR文件就是列表左上角的下载图标。HAR文件记录了一整批请求的完整信息包含URL、请求头、请求体、响应内容、耗时。把文件发给同事对方导入自己的DevTools或其他排查工具就能看到和你的现场一模一样的请求情况。这个做法比截图传话可靠得多因为截图上没有的信息HAR里全都保留了。3. 从抓包结果反推Bug根源一套可复用的判断思路3.1 状态码是排错的方向盘拿到请求结果第一步永远是看状态码。状态码直接告诉你本次请求在HTTP层面的结果我把它当作排错的方向盘。先强调一个容易踩的坑200不代表万事大吉。很多接口就算业务失败HTTP状态码也返回200只在响应体里放一个非0的code字段来标识。所以看到200还要顺手在Preview里确认业务码和数据是否正常。301/302属于重定向页面跳转异常的时候沿着重定向路径看它到底跳到了哪里可能就会发现URL被拼错或者被代理规则带偏。304表示协商缓存生效浏览器直接用了本地缓存。如果你改了后端逻辑但前端页面不更新第一步就应该怀疑是不是它。401和403都和权限相关401一般是没登录或登录态过期403是登录了但没有权限。排查时去请求头里看Authorization和Cookie再配合Application面板看当前存储的数据是不是Token丢了、Cookie过期了一目了然。404说明接口地址对不上号优先排查URL拼写、路由是否存在以及当前环境是不是错了——我见过测试页面把请求打到生产域名的情况接口自然是404。五开头的状态码比如500、502、503基本指明后端或网关出了问题。这时候把请求详情里的响应信息、请求头、请求体完整截给后端远比丢一句“你接口挂了”更有价值。3.2 现场分锅一次400排查的完整复盘拿一个真实项目里反复出现的场景复盘。列表页点击查询后页面弹“系统错误”后端群里问“是不是前端传参错了”前端群里回“我这边请求正常”两边来回拉扯十分钟没有任何进展。而用抓包数据这个问题本可以在半分钟内定论。打开Network找到那个失败的请求状态码400。点开Headers看到Request Headers里Content-Type是application/jsonPayload传参是order_id12345参数名与接口文档完全一致。再往下看响应体后端返回了一段校验错误写的是orderId不能为空。问题一下子就清楚了前后端字段命名不一致一个传的是order_id一个接的是orderId后端解析不到字段自然报校验失败。这种情况下最优解是前后端约定一份统一的接口字段规范所有接口的参数命名、类型、层级都按文档走。抓包在这里起到的作用就是把原本说不清谁对谁错的场面变成一条有据可查的线索。如果前端和后端都查了代码觉得没问题我还有一个对比动作把请求复制成cURL在命令行里直接执行。同样一条请求在命令行里能通浏览器里却报错说明浏览器环境下多携带了某些Cookie或请求头引起冲突命令行里也复现同样的错误那就是代码本身发出去的数据有问题。这个对比能把“环境问题”和“代码问题”快速切分开。3.3 配合Console与Sources把网络请求和代码行为连起来抓包能回答“请求长什么样”但“代码为什么走到了这一步”还需要靠Console和Sources面板。Console里看到红色报错先分清错误类型。SyntaxError说明代码语法写错了括号、引号之类的问题直接跳到对应的行修TypeError最常见的是读取了不存在对象的属性——比如接口返回的数据里没有你期望的某个字段代码还继续在这个字段下面取属性立刻就崩了。看清报错信息里的文件路径和行号点击就能跳到Sources里的对应位置。Sources面板的核心操作是断点。在可能出问题的代码行上加断点重新触发场景代码会停在断点上然后你可以单步执行观察变量的值、请求参数是在哪个环节被修改的。我习惯把Sources和Network配合起来用先确认请求发出前的参数是不是符合预期如果不符合就在数据构建处打断点通常一两步就能找到是哪行代码把参数改坏了。还有一种情况是产品逻辑本身没问题代码和接口都正常但页面显示的却是旧数据。如果在Network里看到from disk cache在Console里输出的值也是旧的就别再怀疑代码没生效了去排查缓存策略和资源版本号。4. 进阶抓包技巧模拟网络、复制现场与重放请求4.1 模拟弱网和断网复现环境型Bug有一类Bug很折磨人平时一切正常一进电梯、一过隧道、网络稍微一卡就出问题。这种Bug在良好的开发环境下根本复现不了好在DevTools内置了网络状态模拟功能。Network面板顶部有一个网络状态选择框默认是No throttling。切换成Fast 3G或Slow 3G后刷新页面加载过程会被明显降速这时候哪些资源加载失败、接口有没有超时、页面有没有做好加载占位都会比正常网络下更显眼。还有一个Offline选项直接模拟完全断网用来测试前端有没有做异常兜底。我曾在移动端项目里发现断网时页面抛出一堆未处理的Promise错误用户看到的却是静默失败没有任何提示就是靠Offline模式复现之后才修好的。如果你需要更精确的网络参数可以添加自定义配置手动设置下载速度、上传速度和延迟。模拟线上弱网环境时建议根据线上监控平台统计的真实网络指标来填参数而不是凭感觉填一个值。4.2 复制为cURL把完整现场交给队友定位接口Bug沟通成本往往比查找成本还高。与其截图加上大段文字描述不如直接把请求转成一条curl命令发给对方。在Network请求列表中右键点击某条请求选择Copy再选Copy as cURLDevTools会生成一条完整的命令行请求包含URL、请求方法、全部请求头、Cookie和请求体。后端同事拿到这条命令不需要登录系统、不需要翻接口文档、不需要猜测复现路径在终端粘贴执行就能看到同样的响应结果。一次线上事故排查里我就是靠这种方式快速让后端锁定了问题范围省掉了前后端反复确认信息的时间。这里要提醒一句cURL里通常包含Cookie等敏感信息在工单系统或者公共群聊里分享时先把敏感字段删掉避免泄露登录态。尤其对接外部团队的时候这个动作能防止不少麻烦。4.3 重放和改造请求做边界测试在Network列表里选中一条请求右键点击Replay XHR就能在不重新操作页面的情况下再发一次同样的请求。这个功能在验证接口稳定性的时候特别好用连续重放同一个请求十几次观察有没有偶发的超时、报错和数据异常。偶发问题用这个方式排查比自己一遍遍点页面高效得多。更实用的玩法是改造请求再发。复制成cURL之后可以在命令行里任意修改Payload、URL和请求头。比如把一个必填参数删掉看后端会不会返回友好提示把字段改成超长字符串、特殊字符、负数、极小的数值观察后端是否有边界校验把请求方法改一下看看接口有没有因为方法使用不当而产生隐患。这类边界测试放在联调之前自己做一遍能规避掉大量上线之后才暴露的稳定性问题。移动端调试也有对应的抓包补充方案。很多真机浏览器支持远程调试手机连上电脑打开浏览器调试模式就能在电脑的DevTools里看到手机页面的Network请求。真机的网络环境、Cookie、UA和模拟器差异很大排查“只在手机上出现”的Bug时这种方式几乎是唯一靠谱的路径。5. 常见问题与排查技巧实录5.1 打开Network却看不到任何请求这是一个高频问题。很多人问我明明页面有接口请求为什么Network面板一片空白原因通常不是工具坏了而是设置在捣乱。最常见的是没有勾选Preserve log。页面一旦发生跳转或者刷新默认情况下之前的请求记录会被清空。尤其有些页面打开瞬间就自动跳转等切到Network面板旧请求早就被清掉了。解决办法是提前勾上Preserve log再重新打开页面触发一次。第二种情况是请求被浏览器插件拦截。部分插件会按规则过滤广告域名或特定接口导致请求没有正常发出。排查方法也很简单临时禁用所有浏览器插件后再试基本能确认是不是插件在捣乱。还有一种是搜索条件或者过滤条件残留了。过滤框里留着之前的关键字或者误触了某些过滤按钮都会让请求列表看起来空空如也。先把过滤条件和搜索框清空再判断问题是否真的存在。5.2 请求一直Pending下不来Pending表示请求已经发出去了但始终没有收到完成信号。这种情况我一般按三条线路排查。第一后端处理慢。接口内部可能有长时间的循环、数据库锁等待或者依赖外部服务导致迟迟不返回。验证方法很直接用接口调试工具直接请求同一个URL如果同样长时间无响应基本可以锁定后端。第二请求体传输问题。Payload特别大或者多文件上传场景请求容易长时间挂起。这时看一眼Size列如果数值异常大就要考虑改成流式传输或确认服务端的接收限制。第三前端自身的问题。比如全局请求拦截器做了不合理的处理或者某段代码卡住了请求发出后的后续逻辑。用排除法逐个环节排查一般都能找到答案。5.3 改了代码不生效多半是缓存这是一个迷惑性很强的问题。代码改了、部署了但用户反馈线上还是旧版本。打开Network大概率能看到静态资源返回304或者Size列显示from disk cache。浏览器认为文件没变直接用了本地缓存。现代构建工具通常会给静态资源文件名加上内容哈希文件名变了缓存自然失效。如果你发现部署后哈希没变要检查构建配置是不是关闭了哈希命名或者服务端有没有错误地剥离版本参数。调试阶段可以用一个临时手段在DevTools里勾选Disable cache然后在开着DevTools的状态下刷新页面强制绕过缓存验证最新代码。但要清楚这个设置只在面板打开期间有效关掉之后缓存策略恢复正常不影响正常用户。5.4 跨域报错集中排查跨域报错在Console里通常显示为类似“has been blocked by CORS policy”的红色消息。原因大多是后端响应头缺失或者配置得不对。在Network里找到被拦截的请求切到Headers看响应头里有没有Access-Control-Allow-Origin。没有这个头后端需要处理跨域配置有但值不对比如写死了某个域名而后端又需要支持多个来源就要调整匹配规则。如果请求需要携带Cookie还要确认Access-Control-Allow-Credentials是否配置正确并且Allow-Origin不能使用通配符。还有一个容易忽略的细节预检请求。某些跨域请求会先发一个OPTIONS请求预检通过之后才会发出真正的业务请求。如果在Network列表里看到OPTIONS请求报错那么主请求自然被浏览器拦掉了。排查跨域问题的时候把OPTIONS请求也纳入观察范围很多“业务请求为什么没发出”的疑问就迎刃而解了。我从过去这些项目经历里最深的一点体会是会不会用F12抓包直接决定了你在团队里是那个“解决问题的人”还是那个“等着别人解决问题的人”。排错能力不是靠聪明堆出来的就是在这一次次打开Network、看Payload、查状态码、对比响应内容的动作里练出来的。最后再分享一个个人习惯我现在遇到前端任何异常都会先按F12让Console和Network先开口说话只有它们排除了网络层和运行时报错我才会去Sources里逐行追逻辑。这套固定动作帮我省下了大量逐行读代码的时间也帮我少背了很多不该背的锅。希望这个习惯对你同样有用。