缓存和 CDN 是把站点变快的好工具，但它们也是「看不见的中间层」。很多运营问题最后排查下来，并不是页面写错了，而是缓存给用户和搜索蜘蛛发了一份过期副本。

缓存出问题时，通常长什么样

• 后台改了标题或正文，前台刷新还是旧内容，过几小时才恢复。
• 上线新栏目，自己能看到，别人打开却是 404 或旧页面。
• 不同地区、不同网络访问到的版本不一致，内容看起来「随机」变化。
• 蜘蛛抓到的页面里，链接指向的却是早已下线的地址。

这些现象的共同点是：源站的改动已经生效，中间层还在交付旧结果。排查时先分清是源站缓存（页面缓存、对象缓存）还是边缘缓存（CDN），能省下不少时间。

自查一：页面缓存与过期时间

先确认被缓存的对象是谁、缓存多久。

• HTML 页面是否被整页缓存？过期时间（TTL）设成多少？
• 登录用户、购物车等个性化页面是否被误缓存？
• 后台发布内容后，是否有自动清理对应 URL 缓存的机制？
• 首页、列表页这类更新频繁的页面，TTL 是否过长？

一个常见做法是：详情页缓存久一点，首页和栏目列表页短一点，并在内容发布、修改、删除时主动刷新相关 URL。不要依赖「等它自己过期」。

自查二：CDN 规则是否和站点结构匹配

CDN 的默认规则往往是「缓存所有可缓存资源」，小站点问题不大，结构复杂时容易出错。

• 动态接口、站内搜索页、带参数的筛选页是否被排除在缓存之外？
• 是否把 404 和跳转响应也长期缓存了？这会让已修复的地址继续报错。
• 回源配置里，源站 IP 变更后是否同步更新？
• 是否正确传递原始协议与主机名，避免出现混合内容或错误重定向？

缓存的默认行为是「尽量少回源」。如果你没有明确告诉它什么不能存，它就会按自己的理解来。

自查三：蜘蛛收到的和用户看到的是否一致

有些站点会对不同 User-Agent 返回不同内容，本意是优化，实际容易出问题。

• 确认没有对搜索蜘蛛返回简化版或纯静态的旧快照。
• 确认 CDN 没有把某个 UA 的响应缓存下来，再分发给其他访问者。
• 确认缓存里的 HTML 中，内链指向的是当前有效 URL，而不是历史版本。

判断方法很简单：用命令行或抓取工具请求同一个地址，对比源站直连和经过 CDN 的结果，看状态码、标题、正文关键段落是否一致。

自查四：静态资源要带版本标识

图片、CSS、JS 这类文件通常缓存时间很长，靠文件名区分版本最省事。

• 资源地址里是否带有哈希或版本参数，例如 style.a1b2c3.css？
• 改版后是否生成了新的资源地址，而不是直接覆盖旧文件？
• 旧的资源文件是否还被其他页面引用？

如果直接覆盖同名文件，用户和缓存都可能继续用旧版本，出现样式错乱、按钮点不动这类看起来像前端故障的问题。

一份可落地的检查清单

1. 列出站点里所有会缓存内容的层：应用缓存、对象缓存、CDN、浏览器缓存。
2. 为每一层写下缓存对象、过期时间、清理方式。
3. 发布流程里加一步：内容上线后主动刷新对应 URL 与相关列表页。
4. 改版或迁移前，先确认 CDN 与缓存规则是否需要同步调整。
5. 每次大改动后，用直连与 CDN 两条路径各验证一次关键页面。

把缓存当成流程的一部分

缓存规范不需要写得很复杂，关键是有人负责、有地方记录。把「发布后刷新哪些地址」「资源变更怎么命名」「异常时先看哪一层」写进站点运维文档，比出事之后一层层试要高效得多。

最后提醒一句：缓存是加速手段，不是发布机制。内容是否被访问到、是否被正确识别，最终还是要以源站的真实响应为准。