缓存的初衷是让重复访问更快，但配置不当的时候，它会变成另一种麻烦：访客看到的是上一次改版前的页面，抓取到的也是旧内容，而你在后台明明已经保存并发布了。缓存本身没有错，问题通常出在没人说清楚“哪一层缓存、缓存多久、谁来清”。
先分清站点上的几层缓存
排查之前，先把链路上的缓存层数清楚，否则很容易改了一层、漏了另一层。
- 浏览器缓存：由响应头控制，缓存在访客本地，服务端无法主动清除，只能等它过期或靠用户手动刷新。
- CDN 或反向代理缓存：位于机房边缘，一般可以主动刷新，但需要知道具体节点和匹配规则。
- 应用层缓存：页面片段、数据库查询结果、对象缓存等，常和发布流程绑定，容易被忽略。
- 模板或静态化缓存：生成 HTML 文件后没有随内容更新而重新生成，页面看上去一直停在旧版本。
看响应头，比翻文档更快
用浏览器开发者工具的 Network 面板或命令行查看响应头，重点看几个字段：Cache-Control 里的 max-age 与 s-maxage，是否带着 no-store、no-cache、private；Expires 与 max-age 是否互相冲突；ETag 和 Last-Modified 是否稳定。如果 HTML 文档被设成很长的 max-age，又没有版本化的文件名兜底，更新就会变得很别扭。
一个常见的经验分界：HTML 文档适合较短的缓存时间或协商缓存，带内容指纹的静态资源才适合长缓存。
静态资源和 HTML 要区别对待
把两者混在一起配置是常见的坑。静态资源文件名里带上内容哈希，就可以放心设置一年期的强缓存；而 HTML、接口响应这类随时可能变化的内容，要么短缓存，要么走协商缓存。否则每次更新都得靠手动刷新 CDN，时间一长就没人记得做了。
缓存与内容更新的矛盾怎么处理
- 发布后主动刷新相关 URL 的 CDN 缓存，并把这一步写进发布流程。
- 首页、列表页这类被频繁缓存的页面，缩短缓存时间或加上短时校验。
- 改版期间给关键页面加版本标记，避免新旧模板混着输出。
- 验证时用无痕窗口或带禁用缓存选项，排除本地缓存带来的错觉。
关于抓取侧的观察
蜘蛛拿到的页面同样受缓存层影响。如果 CDN 长期返回旧版本，抓取结果就与当前内容不一致。可以在发布后观察一段时间服务器日志里对目标 URL 的抓取记录，确认返回内容与预期一致。这件事没有捷径，只能靠发布后回看，而不是发完就当结束。
一份可执行的自查清单
- 列出站点用到的所有缓存层，写清各自的开关位置和生效范围。
- 抽查首页、栏目页、详情页、静态资源的响应头，判断缓存策略是否合理。
- 确认 HTML 与带指纹的静态资源没有共用同一套缓存规则。
- 确认发布流程中包含刷新缓存的步骤，并明确由谁负责。
- 改版或紧急修正后，用无痕模式确认访客实际看到的内容。
- 留一份“缓存异常时的处理顺序”，避免临时手忙脚乱。
缓存策略不需要多复杂，关键是有人知道它存在、知道怎么改、知道什么时候该清。把这几件事固定进日常运维清单，比事后一遍遍猜“为什么页面没更新”要省事得多。