缓存是站点性能的常规手段，但也会带来一类很难排查的问题：后台已经改好了，访客和蜘蛛看到的还是旧版本。做站点运营时，把缓存当成一项需要定期自查的配置来对待，能省下很多“明明改了却没生效”的来回沟通。
缓存为什么会挡住更新的内容
站点通常有多层缓存同时在起作用：浏览器本地缓存、CDN 边缘节点缓存、服务器端页面缓存或对象缓存。一次请求可能被其中任意一层拦住，直接返回之前存下的副本，请求根本没走到源站。
对运营来说，这意味着两件事。第一，更新之后自己刷新能看到新内容，不代表别人也能看到，因为你这次访问可能刚好绕过了某一层。第二，蜘蛛抓到的 HTML 如果来自边缘节点的旧副本，那么新加的链接、调整过的标题、替换掉的正文，都不会立刻出现在它的抓取结果里。
分层自查：从浏览器到源站
1. HTML 和静态资源分开对待
静态资源（图片、样式、脚本）通常带指纹或版本号，可以设较长的缓存时间；而 HTML 是内容变更的主要载体，缓存时间往往需要短很多，或者使用协商缓存，让浏览器每次回源确认一下。
- 检查 HTML 响应头里的缓存指令，确认它的有效期是否合理，是否误用了“一年不变”这类只适合带指纹资源的设置。
- 检查静态资源的文件名是否带版本或哈希。没有指纹又设了长缓存，改动后用户会长期拿到旧文件。
- 确认页面上的关键资源引用路径会随版本更新，而不是固定不变的地址。
2. CDN 的缓存键与查询参数
CDN 判断“这是不是同一个资源”，靠的是缓存键。如果缓存键忽略了查询参数，那么带不同参数的地址可能被当成同一个页面，返回彼此的内容。
- 确认带参数的页面（筛选、排序、分页）是否被配置成忽略参数，导致不同结果互相覆盖。
- 确认是否对不存在的参数组合也做了缓存，避免把错误页面长期留在边缘节点。
- 核对回源协议与回源地址，避免 CDN 走的是测试环境或旧机房。
3. 私有内容与登录态不要被公共缓存
后台页面、用户中心、带登录信息的页面，如果被当成公共内容缓存，风险不只是内容不新，而是可能把一个人的页面发给另一个人。这类地址应当明确排除在公共缓存之外，或按用户区分缓存键。
4. 回源失败时的兜底行为
有些配置在源站超时或报错时会返回之前缓存的旧副本。这在稳定性上有好处，但也会掩盖问题：源站其实已经挂了，外部看着却“一切正常”。自查时要确认这类兜底策略是否开启、开启后是否有告警。
发布完之后怎么验证
更新上线后，建议固定走一遍检查流程，而不是只刷新一次页面就结束。
- 用无痕窗口打开目标地址，排除浏览器本地缓存的影响。
- 查看响应头，确认返回的是新版本标记，而不是旧的缓存命中。
- 如果站点有 CDN，主动提交需要刷新的地址，等待生效后再复查一次。
- 用抓取工具或直接请求的方式，模拟蜘蛛拿到的 HTML，确认里面已经包含新内容。
- 隔一段时间再复查一次，确认没有被边缘节点用旧副本重新填充。
把缓存策略写进运维记录
缓存问题最容易在交接时出岔子：谁改过规则、什么时候清过缓存、哪些路径需要手动刷新，如果没有记录，下一个人只能靠猜。可以在运维文档里固定记下几件事：各层缓存的有效期、缓存键的组成方式、需要手动刷新的路径清单、以及每次改版后执行刷新的时间点。
另外，站点结构或栏目调整时，记得同步检查旧的缓存规则。已经下线的目录如果还留着长缓存配置，可能出现旧地址仍然返回内容的情况，给后续的规范化处理添麻烦。
缓存不是一次配置就一劳永逸的事。把它和内容更新节奏绑在一起，每次发布顺手确认一遍，比事后反复怀疑“是不是服务器有问题”要省事得多。