网站缓存：怎样取得可复查的状态证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ea7ea33e2f55.html
📄
网站缓存：怎样取得可复查的状态证据
要取得可复查的网站缓存状态证据，核心是让每一次判断都能被第三方按同样步骤复现：记录请求与响应头、保存响应正文摘要、注明检测时间与出口网络，并区分浏览器缓存、CDN缓存和服务器端缓存。只截一张“命中缓存”的图不算证据，因为它缺少请求条件、时间戳和对比基线。
先明确你要证明的是哪一层缓存
“网站缓存”在实际项目里至少涉及三层，证据形式不同：
- 浏览器缓存：由
Cache-Control、ETag、Last-Modified等响应头控制，证据是同一 URL 在不同请求下的状态码和头部变化。 - CDN 或反向代理缓存：证据通常是
Age、X-Cache、CF-Cache-Status一类响应头，但不同服务商字段名不同，必须按实际响应记录，不能预设字段一定存在。 - 应用层或对象缓存：页面内容可能来自数据库查询缓存或页面缓存，HTTP 头未必体现，需要结合服务端日志或缓存键说明来判断。
如果目标只是确认“用户是否拿到旧页面”，浏览器层证据通常足够；如果要确认“回源是否被减少”，则需要 CDN 层或服务端日志。两者的取证成本差别很大，先定目标再选手段。
可复查证据的最小组成
一份能被复查的缓存状态记录，建议包含以下字段。缺项越多，复查时越容易得出不同结论。
- 完整请求 URL：含协议、主机、路径和查询字符串。带参数的 URL 与不带参数的 URL 可能是不同的缓存键。
- 请求方法与请求头：至少记录
GET或HEAD，以及是否携带Cookie、Authorization、Accept-Encoding。这些头可能直接改变缓存行为。 - 响应状态码与关键响应头：如
200、304、Age、Cache-Control、ETag、Vary。 - 响应正文摘要：对正文计算哈希，或保存正文长度与关键片段，用于判断两次响应内容是否一致。
- 时间与出口信息：请求发生的 UTC 时间、发起请求的网络或地区。CDN 缓存具有节点差异，同一时刻不同地区结果可能不同。
命令行取证可以用 curl，把响应头和正文分开保存：
curl -sS -D headers.txt -o body.bin "https://example.com/page"
随后对 body.bin 计算哈希，并把 headers.txt 与哈希值一起归档。这样复查者可以重放同一请求，对比头部和正文是否变化。示例中的域名仅作占位，实际使用时替换为待测 URL。
对比测试：判断缓存是否生效的执行步骤
单次请求只能说明“此刻返回了什么”，不能证明缓存策略是否按预期工作。更可靠的做法是做一组有对照的请求：
- 连续两次请求同一 URL，间隔数秒，记录两次的
Age和正文哈希。若第二次Age增大而正文哈希不变，说明中间层很可能复用了缓存。 - 再发一次带
Cache-Control: no-cache的请求，观察状态码是否变为304或回源返回200。这能帮助区分“缓存命中”和“源站每次都返回相同内容”。 - 从不同网络出口重复第一步。如果不同地区结果不一致，说明缓存存在节点或地域差异，不能用一个节点的结果代表全局。
- 把上述记录按时间排列，标注每次请求的条件。复查者按同样顺序重放，就能判断结论是否稳定。
适用条件是：你能控制或至少能观察到请求头，并且目标 URL 允许被重复请求。如果页面依赖登录态或个性化内容，缓存行为会因 Cookie 不同而变化，此时应先固定测试身份，或改用不携带登录态的公开 URL 做基线。
证据的局限与判断结果
即使记录完整，也要注意几类边界。第一，Age 存在不等于内容一定正确，它只说明响应经过了一段缓存时间。第二，304 表示协商缓存生效，但不代表 CDN 边缘节点命中了缓存。第三，正文哈希一致可能只是源站内容未变，不能单独证明缓存层起了作用，需要结合 Age 或回源日志交叉判断。
如果复查者按你的记录重放后得到不同结果，优先检查三项：请求头是否一致、出口网络是否相同、测试时间是否落在缓存过期边界附近。把这三项写进记录，比事后解释更有用。
下一步，选一个你正在维护的页面，按上面的字段做一次双请求对比，把头部、正文哈希和时间归档。若结果无法复现，先补齐请求条件和出口信息，再判断缓存策略是否需要调整。
