很多站点都会遇到这种情况：后台显示已经发布，编辑在预览里也看到了新版本，但访客看到的、搜索蜘蛛抓到的，还是几小时甚至几天前的旧页面。这时候第一反应往往是“是不是没发布成功”，于是反复点一次发布，结果问题依旧。多数情况下，问题不在发布环节，而在内容到访客之间经历的那几层缓存。
缓存不是故障，是没对齐
缓存本身是好事，它把重复计算的结果存下来，减少服务器压力，也让页面打开更快。麻烦的是，当内容更新时，如果缓存层没有同步失效，新旧版本就会同时存在：编辑看到新的，部分用户看到旧的，不同地区的 CDN 节点还可能各说各话。
所以真正要做的，不是把缓存一关了事，而是让“什么内容、缓多久、什么时候必须失效”这三件事有明确规则。
分层自查清单
1. 浏览器缓存与缓存头
- HTML 文档的 Cache-Control 是否设了过长的 max-age。正文页通常不适合让浏览器长时间缓存，页面级内容变动频繁时尤其要注意。
- 静态资源（CSS、JS、图片）可以长缓存，但文件名里建议带版本号或内容指纹，否则更新后用户拿到的还是旧文件。
- 检查是否同时存在 ETag 与 Last-Modified，两者判断逻辑不一致时，部分客户端会一直认为自己手上的副本仍然有效。
2. CDN 层
- 哪些路径被规则判为可缓存，哪些被排除。常见的坑是把整站 HTML 一起纳入缓存，却在更新时只刷新了首页。
- 刷新方式的区别要弄清楚：URL 刷新只清具体地址，目录刷新会影响一批页面。频繁全量刷新既慢又消耗额度，最好按栏目分批处理。
- 回源策略是否合理。回源频率过高会让源站压力变大，过低又会导致内容迟迟不更新。
- 如果 CDN 会压缩或改写 HTML，确认缓存的是改写前还是改写后的版本。
3. 服务器端缓存与对象缓存
- 页面缓存（如整页静态化、反向代理缓存）的失效规则是按时间触发还是按事件触发。
- 对象缓存、查询缓存是否在内容保存时被主动清理。很多系统只在特定操作后才清缓存，批量导入或直接改数据库时不触发。
- 多台应用服务器之间是否存在缓存不同步，导致刷新后请求落到另一台、仍然返回旧内容。
4. 页面自身的静态化产物
- 如果站点会生成静态 HTML 文件，确认新内容是否覆盖了旧文件，而不是生成到了另一个目录。
- 检查是否存在多份同名模板产物，实际对外服务的可能不是刚更新的那一份。
更新后的验证顺序
- 先在源站直接访问，用带随机参数的地址排除本地缓存干扰，确认源站返回的是新版本。
- 再通过 CDN 域名访问，观察响应头里的缓存命中状态和过期时间。
- 换一个网络环境或使用匿名窗口再看一次，确认不是本机缓存造成的错觉。
- 抽查同栏目下的其他页面，确认刷新范围没有波及无关内容，也没有漏掉应该更新的页面。
- 把这次更新的缓存处理方式记进发布流程，下次同类内容按同样的步骤走。
和抓取、收录的关系
缓存不同步对搜索蜘蛛的影响是间接的：蜘蛛拿到的是旧版本，就可能把已经修改过的标题、描述、正文重新当成旧内容处理。这不意味着更新一定不会生效，而是会拖慢变化的传递速度，也可能让页面在搜索端的呈现长期落后于实际内容。
把“内容发布”和“缓存刷新”当成同一个动作的两个步骤，而不是两件事。发布完成后顺手确认一次缓存状态，比事后反复排查省事得多。
把规则写下来
缓存策略最怕的是只存在于某个人脑子里。建议在运维或发布文档里固定几行内容：哪些目录可以长缓存，哪些必须短缓存，更新某类内容时刷新哪些路径，由谁执行。规则稳定之后，编辑只管写内容，技术只管维护规则，中间那层不确定性就少了很多。
另外，缓存刷新不需要每次都做全站。大多数日常更新只涉及一两个栏目，按范围刷新既快又不容易误伤。真正需要全量刷新的场景其实很少，通常是模板、样式或导航结构整体调整的时候。