缓存是为了让访问更快、回源更少，但它也会把某一刻的状态固定下来。站点运营中常见的“我明明改了，怎么还是旧的”，多数不是发布没生效，而是缓存还在用旧副本。下面这套自查不做复杂配置，只确认几件容易漏掉的事。
先列出哪些地址被缓存
不同类型的资源，缓存策略不该一样。先把站上会被缓存的地址分个类，再逐类确认。
- HTML 文档：更新最频繁，缓存时间通常最短，发布后往往需要主动刷新。
- 静态资源：CSS、JS、图片、字体适合长缓存，但要靠文件名或版本号变更来触发更新。
- 接口与 JSON：确认是否被 CDN 或浏览器缓存，避免前端展示旧数据。
- 错误页与跳转：404、410、301、302 是否被长时间缓存，这是最容易踩坑的地方。
- robots.txt、sitemap.xml、RSS：这些文件会被反复读取，缓存过久会让规则与地址清单滞后。
三个高频问题
状态码被一起缓存
页面在上线前的短暂 404，或者一次误配的 301，如果带着长缓存头返回，缓存节点会把这份答案留着。后续内容恢复了、跳转改对了，来访者与抓取工具拿到的仍是旧状态。自查时用 curl -I 分别请求一个正常地址、一个已知不存在的地址和一个重定向地址，看它们的 Cache-Control 与 Age 是否合理。
缓存键与查询参数
同一内容如果带着不同参数被反复请求，可能生成多份缓存副本，既占空间也模糊命中统计。反过来，如果缓存键忽略了关键参数，A 参数的内容会被 B 参数的请求命中。先确认缓存键包含哪些部分，再决定要不要在入口层把参数收敛掉。
刷新与回源
发布流程里要有一句明确的“刷新哪些地址”。只刷首页通常不够，列表页、详情页、栏目聚合页往往各有缓存。也可以用版本化文件名让静态资源自然过期，减少手工刷新带来的遗漏。
一页自查清单
- 用 curl -I 查看响应头中的 Cache-Control、Age、ETag、X-Cache 等字段，判断副本来自哪一层。
- 对比带参数与不带参数的同一地址，看返回内容与缓存状态是否一致。
- 检查 404、410、301、302 是否带有长缓存，必要时缩短。
- 确认 robots.txt、sitemap.xml 的缓存时间在可接受范围内。
- 改动发布后，按清单刷新相关地址，并再次请求核对实际返回。
- 把回源日志与 CDN 命中统计对照，观察是否出现异常的回源量或缺失的记录。
缓存不是问题，不确定缓存里放的是哪一版才是问题。把“改了哪里、刷了哪里、怎么确认”写进流程，比临时清一次缓存更省事。
建议每季度做一次，在大改版、换域名、调整目录结构之后更要补做。确认这几件事，站点在访问速度和内容一致性上都会更可控。