Chrome DevTools 怎么查看请求响应头：Network、Headers 与缓存核对

接口明明返回了200状态码，页面却始终展示旧数据，排查的时候别死盯着后端日志浪费时间。打开Chrome浏览器的开发者工具Network面板，点中实际触发的那笔请求，再切到Headers标签核对状态码、请求头、响应头和缓存相关提示，通常几分钟就能定位问题到底是请求根本没发出去、响应被本地缓存拦截，还是服务端返回的内容本身就不对。

先在Network面板里重新触发一次目标请求，再沿着Headers下的General、Response Headers、Request Headers三个模块依次核对；要是看到“Provisional headers are shown”提示，优先排查缓存或是这笔请求有没有真的走完整网络链路。

先让目标请求出现在Network列表里

打开Chrome目标页面后按 Command + Option + I（macOS系统）或 Control + Shift + I（Windows、Linux系统），在弹出的开发者工具里点顶部的Network标签。只要DevTools保持开启，Network面板就会自动记录页面后续产生的全部网络请求；如果面板开得太晚，之前已经加载完成的请求不会自动补回列表。

排查单个接口问题时，先点面板上的清空按钮，再刷新一次页面，最终列表里剩下的都是本次页面加载过程中产生的请求，避免把之前的旧请求、浏览器扩展发起的无关请求和真正要排查的目标混在一起。针对接口调试场景，可以在Filter输入框里填入接口路径的部分内容，或者直接选择Fetch/XHR类型来进一步缩小筛选范围。

选中请求后先看General状态

在请求列表里点一下目标请求的名称，右侧就会展开这笔请求的全部详情。Headers页签的General区域适合做第一轮快速判断：确认Request URL是不是指向你预期的后端地址、Request Method和接口约定的请求方式是否匹配，以及状态码和对应的状态提示文字有没有异常。

比如页面显示旧数据的场景，先确认请求URL没被错指向测试域名，状态码也不是304这类代表资源走缓存的重定向标识。先把“请求发去了哪里、服务器实际回了什么”这两个信息确认清楚，比上来就盲目猜测缓存问题效率高很多。

在Headers里分别核对响应头和请求头

Response Headers 看服务器给出的规则

接着往下看Response Headers区块，这里可以检查 Cache-Control、ETag、Last-Modified、Content-Type 这类实际从服务端返回的响应字段。如果接口约定返回的是JSON格式，那Content-Type字段的值就应该和预期一致；要是缓存相关字段的规则和你预想的不符，可以把这组响应头完整截下来和后端同事一起核对排查。

Request Headers 看浏览器实际带了什么

Request Headers区块里可以核对请求发出去时浏览器实际携带的Host、Accept、Referer、Cookie等字段。排查跨域问题的时候，还要额外留意Origin字段是否正常；调试需要登录态的接口时，则要确认当前请求有没有真的带上对应的身份凭据。不要把完整的Cookie内容直接复制到公开工单或是对外截图里，必要的时候只保留字段名和打码脱敏后的值就行。

缓存问题用 Disable cache 做一次对照

要是怀疑浏览器直接复用了本地旧资源，你可以在Network面板里勾选Disable cache选项，之后重新加载页面。这个选项只会在DevTools保持打开的期间生效，作用是模拟用户第一次访问页面、完全不使用本地浏览器缓存的场景。对照排查的时候要重新点选目标请求，观察Response Headers内容和Size数值有没有发生变化。

注意不要把Disable cache当成线上问题的修复方案，它只是一个本地排查用的开关：如果关闭缓存后页面内容立刻更新成最新版，下一步就要回到服务端检查Cache-Control、ETag或是资源版本号相关的策略；如果结果还是和之前一致，就继续顺着请求URL、响应体、接口返回数据的方向往下排查。

搜索和筛选：列表太长时别靠肉眼翻

Network自带的Filter功能支持按不同属性过滤请求，例如 domain:、resource-type:、scheme: 等场景，也可以直接输入路径的部分片段做匹配。需要在请求头、传参Payload或是响应内容里找某个特定字段的时候，用Network面板自带的全局搜索功能，输入 Cache-Control 或是接口返回里的固定特征字段，命中关键词后DevTools会自动定位到对应的请求，直接展开详情页。

拿到筛选结果之后还是要回到Headers模块做最终核验，不要误以为在过滤列表里“看到了请求”就等于“已经确认响应内容完全正确”。能作为有效结论的排查记录至少要包含请求URL、状态码、关键响应头、是否绕过本地缓存这四项信息。

常见问题：Chrome DevTools 请求头怎么看

为什么 Headers 里只有 Provisional headers are shown？

官方文档标注的常见原因包括请求直接从本地缓存读取、对应资源本身无效，或是浏览器出于安全策略只展示临时生成的请求头。你可以先勾选Disable cache选项重新加载页面，要是提示仍然存在，再进一步检查请求URL和页面本身的安全配置规则。

Network 里找不到刚才的请求怎么办？

先确认你要排查的请求发起之前Network面板就已经处于开启状态，之后清空现有列表再刷新一次页面。也可以检查是不是开了不合适的类型筛选，把目标请求误过滤掉了。

看响应头要点哪个位置？

选中请求列表里的目标请求，打开Headers标签，往下滚动就能依次看到General、Response Headers和Request Headers的全部内容。需要按服务器原始返回顺序查看字段时，点对应区块旁边的view source选项就能看到原生格式内容。

Disable cache 开了为什么刷新后还不对？

这个选项只会影响浏览器本地缓存逻辑，不会修改服务器实际返回的数据。重新加载后如果响应内容还是不符合预期，应该顺着URL正确性、状态码、响应体内容以及服务端侧缓存策略的方向继续排查。

把一次排查结果留成可复核记录

完成全部检查步骤后，建议随手记录下请求URL、请求方法、状态码、关键响应头、是否开启了Disable cache，以及前后两次刷新的结果差异。之后再遇到“页面内容不更新”这类问题时，你就能快速区分出问题属于浏览器缓存、请求路由异常还是服务端响应出错，也不会只凭着一张信息不全的模糊截图就下判断。