网站缓存，怎样检查前后环节的依赖
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /72e362d57098.html
📄
网站缓存，怎样检查前后环节的依赖
检查网站缓存的前后依赖，核心是沿“请求进入—缓存判定—回源—响应写入—浏览器复用”这条链逐段验证，而不是只看某一层是否命中。对已有页面或项目做改进时，先确认每一环的输入来自哪里、输出交给谁，再决定改哪一层，代价最小。
先画出一条请求链，标出缓存层级
一次页面访问通常经过这些环节：浏览器缓存、CDN 或反向代理缓存、应用层缓存（页面缓存、对象缓存）、数据库查询缓存。它们不是并列关系，而是前后依赖：浏览器命中就直接结束，不会触发后面任何一层；CDN 命中就不会回源；回源后应用层缓存未命中，才会查数据库。
因此检查依赖时，先回答三个问题：
- 这一层的输入是谁给的？（用户请求、上一层缓存、还是回源响应）
- 这一层的输出交给谁？（直接返回用户，还是写入下一层）
- 这一层的失效由谁触发？（时间过期、内容更新、手动清除）
画不出这条链，就无法判断“改了缓存却没生效”是改错了层，还是上层把旧结果挡住了。
用响应头判断请求停在了哪一层
最直接的检查手段是看响应头，逐层比对：
Cache-Control与Expires：决定浏览器和中间缓存能存多久。若Cache-Control: no-store，后面几层基本不会被复用。Age：出现且数值大于 0，说明响应来自共享缓存，不是刚回源。X-Cache、CF-Cache-Status一类自定义头：不同服务商字段名不同，需要按实际配置核对，不能假定字段一定存在。ETag与Last-Modified：决定协商缓存能否返回 304，影响回源频率。
判断结果：如果连续两次请求的 Age 递增，说明请求停在共享缓存；如果每次都从零开始且响应头带应用层标记，说明上层没接住，需要检查上层配置而不是应用缓存。
区分“可能原因”和“已经定位的原因”
同一现象往往有多种解释，不要急着下结论。例如“更新内容后页面还是旧的”，可能原因包括：
- 浏览器本地缓存未过期，用户端仍用旧副本；
- CDN 边缘节点缓存未失效，回源请求根本没发出；
- 应用层页面缓存未清除，回源拿到的仍是旧页面；
- 对象缓存或查询缓存返回旧数据，页面重新生成但内容源是旧的。
要把它变成“已经定位的原因”，需要逐项排除：换一个无缓存环境或加随机查询参数请求，看是否变化；直接请求源站地址，绕过 CDN，看是否变化；清除应用层缓存后再请求，看是否变化。每排除一层，依赖关系就清晰一段。注意，robots.txt 的抓取限制不等于可靠的索引移除，它和缓存失效是两回事，不要混用。
按代价从低到高选择改动点
确认依赖链后，改动点不同，代价差别很大：
- 只调浏览器缓存时长：改动小，但只影响重复访问的用户，对首次访问和共享缓存无效。
- 调 CDN 缓存规则：影响面大，需要确认失效机制是否覆盖内容更新路径，否则会出现旧内容长期驻留。
- 改应用层缓存策略：需要同步考虑清除逻辑，代价中等，但能控制回源压力。
- 改数据层缓存：影响最深，出错时排查链最长。
选择步骤可以固定为：先确认问题停在哪一层，再判断该层失效由谁触发，最后选择能覆盖这个触发路径的最小改动。若只是想让编辑更新后立即可见，优先检查 CDN 与应用的清除联动，而不是整体缩短所有缓存时间。
把检查固化成可重复的步骤
建议每次改动前后都执行同一套检查：
- 用无痕窗口或禁用缓存的方式请求目标 URL，记录响应头中的缓存相关字段。
- 直接请求源站，与经过 CDN 的响应对比，确认差异来自哪一层。
- 触发一次内容更新，观察各层是否按预期失效，记录生效所需时间。
- 若使用站点地图或索引相关配置，单独验证，不要把它当作缓存生效的证明；站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名提升。
下一步：挑一个你正在维护的页面，按上面的响应头清单记录一次完整请求链，标出每一层的输入与输出，再决定改动点。
