为什么缓存会成为运营变量
内容更新后，源站已经生效，访客和蜘蛛却可能还看到旧版本。这通常不是“蜘蛛没抓”，而是缓存层没有同步。缓存本身是好事，它能降低源站压力、加快首屏；问题出在缓存策略不统一：有的节点缓存十分钟，有的缓存十二小时；有的页面按 URL 缓存，有的还按 Cookie 或 UA 分版本。结果同一个地址在不同时间、不同节点返回不同内容，外部观察到的行为就显得没有规律。
先分清有几层缓存
排查前把链路列清楚，通常至少三层：
- 浏览器缓存：由 Cache-Control、Expires 控制，影响的是回访访客。
- CDN 边缘缓存：由节点规则、缓存键、TTL 决定，影响首次访问的速度和内容版本。
- 源站或应用缓存：页面缓存、对象缓存、数据库查询缓存等，影响更新是否能立刻反映。
三层里任何一层没跟上，外部看到的都可能不是最新内容。自查的重点，是确认这三层对同一个 URL 的判断是否一致。
几个容易踩的坑
HTML 被当成静态资源长缓存
图片、CSS、JS 长缓存没问题，因为文件名里通常带版本号。文章页、栏目页这类 HTML 如果也设了很长的 max-age，更新后访客要硬刷新才能看到，蜘蛛也会在一段时间里反复看到旧内容。更稳妥的做法是给 HTML 较短的 TTL，配合 ETag 或 Last-Modified 做校验。
缓存键忽略了关键差异
如果站点对移动端和桌面端返回不同模板，缓存键里就要包含对应的标识，并让 Vary 头与之一致；否则移动端访客可能拿到桌面版页面，或者反过来。同理，多语言、登录状态、灰度分组都可能需要独立缓存键。缓存键太粗，页面会串；太细，命中率会掉，需要按实际差异决定。
错误页被缓存
源站抖动时返回的 5xx，或者某个不存在的路径返回的 404，如果在边缘被缓存下来，就会持续对外输出错误页。要检查 CDN 是否对 4xx、5xx 设置了短缓存或不缓存，并确认有对应的清理手段。
自查的几种做法
- 用命令行多次请求同一 URL，观察响应头里的缓存状态字段（不同厂商命名不同，常见有 Age、X-Cache 之类），确认是否命中、TTL 还剩多久。
- 从不同地区或不同网络发起请求，对比返回正文的关键片段是否一致，尤其是刚更新过的页面。
- 更新一篇内容后，记录源站生效时间、缓存清理时间、外部可见时间，连续做几次，找出平均延迟。
- 检查缓存规则里是否对 HTML、接口、图片分别设置了不同策略，避免一刀切。
- 确认清理流程有记录：谁触发、清了哪些 URL、多久生效。
把确认动作放进更新流程
与其事后猜测，不如把“发布后确认外部可见”写进日常流程。更新页面少时手工核对即可；数量多时，抽样检查主栏目页、新发布页和被改动过的旧文。核对时重点看状态码、页面标题、正文首段这三处，最容易发现拿到了旧版本。
缓存不是问题，缓存策略不一致才是问题。让每一层对“这个地址现在应该返回什么”有同一个答案，访客和蜘蛛看到的内容才不会分叉。