缓存头是什么
缓存头决定资源是否需要重新向服务器确认：Cache-Control 的 max-age 与 no-store、绝对时间的 Expires，以及由 ETag 与 Last-Modified 组成的协商缓存机制。判读方法是看响应码与头的组合：200 配较大的 max-age 说明浏览器可直接使用本地副本；304 说明协商成功、服务器确认资源未变，节省了实体传输但仍然付出一次往返；no-store 则完全跳过缓存。需要注意的是协商请求本身也是往返，在高延迟链路上流量省了，等待时间却未必缩短。
基本信息
| 协议依据 | RFC 9111（HTTP 缓存） |
|---|---|
| 相关头 | Cache-Control、Expires、ETag、Last-Modified |
| 抓包字段 | http.cache_control、http.response.code |
| 关键组合 | 200 配 max-age、304 配条件请求 |
| 层级关系 | CDN 与浏览器各自独立缓存 |
典型使用场景
- 首屏优化：确认静态资源能否走本地缓存，减少往返次数
- 协商成本评估：统计 304 的比例，判断是否还有优化空间
- 配置核查：确认 CDN 与源站的缓存策略是否一致
- 变更后异常排查：资源更新但用户仍拿到旧版本，检查缓存时长设置
- 流量核算：把 304 与 200 分开统计，避免体积数据失真
过滤与判断
过滤与判断
http.cache_control contains "no-cache" # 每次都要验证
http.cache_control contains "max-age" # 相对缓存时长
http.response.code == 304 # 协商缓存命中
http.request && http.if_none_match # 条件请求是否发出响应形态判读
| 响应形态 | 含义 | 成本 |
|---|---|---|
| 200 且 max-age 较大 | 本地缓存可直接使用 | 无往返 |
| 304 | 协商确认资源未变更 | 一次往返，无实体传输 |
| no-store | 完全不缓存 | 每次完整传输实体 |
| Expires 已过期 | 需要重新验证 | 一次往返加可能的实体传输 |
CDN 与浏览器是两层独立缓存，同一资源可能某一层命中而另一层未命中；分析时把层级标清楚，否则两边的统计口径会互相矛盾。
服务器与客户端时间偏差较大时，Expires 这类绝对时间头容易失效；改用相对时间的 max-age 更稳妥，排查时也应当优先看它。