如何查找网页请求信息

打开浏览器按F12，何查切到Network标签，找网刷新页面，页请几十条请求瞬间刷出来。求信大多数人看到这堆密密麻麻的何查URL就头皮发麻，直接关掉。找网其实这玩意儿没那么玄乎，页请只要抓住几个关键点，求信你就能像看体检报告一样读懂网页的何查每一次呼吸。

先别管那些乱七八糟的找网图片和CSS文件，找那个名字最像接口地址的页请请求——通常带api、v1、求信data这类关键词，何查状态码200的找网那种。点开它，页请右边会弹出详情面板。Header栏里藏着所有“元信息”，其中Request Headers里的User-Agent就是你的浏览器在自报家门，Cookie则是服务器的通行证。有一次我帮朋友排查登录失效问题，发现就是Cookie里的token过期了，前端没自动刷新，后端就死活不认人。

真正有意思的是Payload或Request Body。这里记录了你刚才在页面上做的每一个动作——填的表单、点的按钮、拖的滑块，全被序列化成键值对躺在里面。我见过最离谱的案例是某电商网站，程序员把商品价格直接写在请求参数里，用户改个数字就能低价下单。你能在Payload里看到price=99这样的明文，这设计简直像把保险柜钥匙贴在门框上。

响应部分也别放过。点开Response，服务器返回的JSON或HTML就摊在你面前。看字段名就能猜出业务逻辑，比如status:1代表成功，error_code:403就是没权限。有次我调试一个爬虫，发现目标网站把关键数据藏在Response Headers的X-Signature里，不抓包根本发现不了。

光看单个请求不够，得学会看瀑布图。Network面板底部那条时间线，每个请求都是横条，颜色深浅代表等待时间和下载时间。哪条横条特别长，哪块就是性能瓶颈。上周我优化一个慢到爆炸的后台系统，顺着瀑布图发现有个接口要串行调用5次数据库，改成并行后加载时间从8秒缩到1.5秒——这比看任何性能报告都直观。

熟练以后你会形成条件反射：页面数据不对，先看请求参数有没有带对；接口报错，看状态码是4xx还是5xx；请求正常但页面空白，查响应结构是不是变了。这套流程走下来，八成问题能定位。剩下的两成，多半是后端悄悄改了字段名没通知前端，这种事我一个月能碰上三回。

最后提醒一句，别光看XHR和Fetch类型的请求。有些网站把数据藏在WebSocket里，或者用JS动态生成URL。遇到这类情况，把Filter里的All勾上，再刷新一次页面，所有妖魔鬼怪都会现出原形。你只要记住：网页的每一次信息流动，都会在Network里留下指纹。学会看它，就等于拥有了透视网页的X光眼。