网站缓存，检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /15d331d509ee.html
📄
网站缓存，检查前需要准备哪些信息
检查网站缓存前，最需要准备的是四类信息：缓存类型与生效层级、当前缓存策略配置、可复现的访问样本，以及能对照的源站响应。缺了其中任何一项，后面的判断都容易变成猜测。第一次接触这个问题时，建议先花十分钟把下面这份清单填完，再动手改配置或清缓存。
先分清你要检查的是哪一层缓存
“网站缓存”不是单一对象。同一个页面可能同时经过浏览器缓存、CDN 边缘缓存、反向代理缓存、应用层对象缓存和数据库查询缓存。不同层级的生效范围、清理方式和排查入口完全不同。如果连层级都没分清，就会出现“清了浏览器缓存但 CDN 还在返回旧内容”这类反复。
准备阶段先记录三件事：
- 用户访问链路：浏览器 → CDN → 反向代理 → 应用 → 数据库，标出你怀疑出问题的那一段。
- 该层缓存的标识方式：是
Cache-Control、Age、X-Cache，还是应用内部的缓存键。 - 谁有权清理：浏览器缓存只能由终端用户清，CDN 缓存通常需要在控制台刷新，应用缓存往往要重启或调接口。
判断结果的方式很直接：如果同一 URL 在不同网络、不同设备上返回内容不一致，问题大概率在共享缓存层；如果只在某个浏览器里异常，先怀疑本地缓存。
准备可对照的请求与响应样本
缓存问题的核心是“同一请求，两次响应是否一致”。所以检查前要固定一组样本，而不是随手刷新页面。建议至少准备：
- 一个具体 URL，最好包含查询参数，例如
/list?page=2。 - 两个观察点：一个已登录或带 Cookie 的请求，一个匿名请求。缓存常因 Cookie 或
Vary头表现不同。 - 完整的响应头，重点看
Cache-Control、Expires、ETag、Last-Modified、Age、Vary。 - 响应体的关键字段或时间戳，用来判断内容新旧。
这些样本要能重复获取。可以用浏览器开发者工具的 Network 面板，也可以用命令行工具记录。把两次结果并排放在一起，比反复口头描述“好像没更新”有用得多。
确认源站当前的真实行为
缓存配置写在服务器、CDN 或应用代码里，但实际行为可能和配置不一致。检查前需要拿到源站的直接响应，作为对照基准。做法是绕过 CDN 或代理，直接请求源站 IP 或源站域名，记录它返回的头信息和内容。
需要核对的检查项包括：
- 源站是否本身就在返回带缓存指令的响应，还是由 CDN 追加。
- 动态页面是否被错误地加上了长缓存时间。
Set-Cookie是否出现在可缓存响应里，这通常意味着缓存策略需要调整。- 是否存在
Vary: User-Agent这类容易被忽略但影响命中率的设置。
如果源站响应和 CDN 返回不一致，先记录差异，不要急着改。差异本身就是定位问题的线索。
把 robots.txt 和站点地图与缓存问题分开
很多人在检查缓存时会顺手看 robots.txt 和站点地图，但这两者解决的是抓取与发现，不是缓存。robots.txt 的抓取限制不等于可靠的索引移除；站点地图也不保证收录。它们可以作为背景信息记录，但不要用“改了 robots.txt”来解释缓存没更新。
同理，HTTPS 不保证安全无漏洞或排名提升，和缓存是否命中没有直接因果关系。检查缓存时，把注意力放在响应头和缓存键上。
实施与验证：先改一处，再复测同一组样本
准备完信息后，实施阶段最重要的原则是一次只改一个变量。比如先调整某个路径的 Cache-Control，然后重新请求之前记录的那组 URL，对比响应头中的 Age 和内容时间戳是否变化。如果同时改了 CDN 规则和源站头，就无法判断是哪一处生效。
验证时区分“可能原因”和“已经定位的原因”。例如“页面返回旧内容”可能有多种解释：CDN 未刷新、浏览器本地缓存、应用层缓存未失效、或者源站本身返回的就是旧数据。只有通过逐层对照样本，才能把可能原因收敛为已定位原因。
维护阶段：留下可复用的记录
缓存问题会反复出现，所以每次检查后应留下简短记录：检查的 URL、当时的响应头、改了哪一层、复测结果。这样下次出现类似现象时，可以直接对比，而不是从头再来。记录不需要复杂，一张表或一段文本即可。
下一步建议：打开浏览器开发者工具的 Network 面板，选一个你怀疑有缓存问题的 URL，勾选 Disable cache 前后各请求一次，把两次的响应头复制出来对比。这一步能帮你确认问题是否真的出在缓存层，再决定要不要动 CDN 或源站配置。
