这条提醒一出：91官网 | 关于缓存设置的说法——我把过程完整复盘了一遍。据说后面还有更大的反转
引子 前几天，网站上出现了一个“老版本内容一直被展示”的问题。用户反馈、我的亲测、以及后台日志把矛头都指向“缓存设置”，于是我决定把整个排查与修复过程从头到尾复盘给大家看——不仅讲过程，还把那些容易被忽视的坑一并列出来。最后我还会拆解一个后来发现的“大反转”，对日常运维和发布流程会有直接的借鉴意义。
背景与症状
- 场景：91官网某栏目更新文章后，首页和部分页面仍然展示旧内容，刷新、清空浏览器缓存无用。
- 初步观察：部分用户能看到新页面，部分用户看到旧页面；移动端与桌面端情况不完全一致。
- 初步判断：可能为多层缓存（浏览器、CDN、反向代理、服务器缓存）某处配置不当或未被正确清除。
我怎么一步步排查（可复现性步骤） 1) 确认 HTTP 头
- 用 curl 检查响应头：curl -I https://example.com/xxx
- 重点看：Cache-Control、Expires、ETag、Last-Modified、Vary、Set-Cookie
- 常见问题示例：服务器返回 Cache-Control: max-age=31536000 导致资源被长期缓存；或返回 no-cache 但 CDN 覆盖了该头。
2) 本地排除法
- 使用无痕窗口和其他网络（手机数据、不同运营商）对比，确认是否为运营商/ISP 缓存或路由问题。
- 清除 Service Worker：很多站点启用了 service worker，会自己管理缓存并在更新策略上产生“假死”现象。
3) CDN 与中间层检查
- 登录 CDN（例如 Cloudflare、Fastly、阿里云 CDN）检查 Page Rules、缓存策略，查看是否开启了“Ignore Query String”或设置了强缓存。
- 尝试 Purge（清理）缓存：先清理单个 URL，再 clean all（注意风险）。
4) 源站与发布流程
- 检查源站是否真的输出最新内容（直接 hit origin server）。
- 检查自动化部署脚本：是否在部署后触发了覆盖操作、或者旧版本的静态文件被重新推回。
5) 复现与验证
- 每次修改后用 curl + 浏览器 + CDN 日志同时验证，确保每一层都被同步更新。
我遇到的问题与解决细节
-
问题一：源站已经输出新内容，但大多数用户仍看到旧页面。 处理：发现 CDN 的 page rule 把某路径设置为 30 天缓存，清理后恢复。
-
问题二：即便清理 CDN，个别用户仍然看到旧内容。 处理：定位到他们的浏览器装了 PWA（service worker）。注销 service worker 并强制刷新后问题消失。解决方案是在 service worker 更新逻辑里加入更稳健的版本判断，或者在发布时发送通知 forcing update。
-
问题三：修完后一天又复现。 处理：追溯部署流水线，发现 nightly-job 会把旧静态文件从备份目录同步回产线，且没有触发 CDN 清理。永久修复在于：把构建产物做内容哈希（content-hashed filenames）并在部署脚本中加入自动化的 CDN purge hook，确保每次发布都有一致的缓存策略与版本化文件。
典型配置示例（供参考）
- 动态页面（需要实时更新）：Cache-Control: no-cache, must-revalidate
- 静态资源（按版本管理）：Cache-Control: public, max-age=31536000, immutable
- 开发/测试环境可短期使用：Cache-Control: no-store
那些容易忽视的坑
- Service Worker：把它当作“不可见的缓存层”，很多人忽略它。
- CDN 的“页面规则优先级”：有时更具体的规则被更高优先级的全局规则覆盖。
- 部署回滚/备份策略：自动化脚本可能在午夜把旧资源误还原。
- 浏览器拓展或代理：有些广告过滤或加速插件会缓存或替换内容。
后面的“大反转”（我亲历的那一幕） 我以为把 CDN 设置改好、清理缓存、修部署脚本就万事大吉。结果两天后问题又来了。追查日志发现：某个第三方统计/加速插件在凌晨不断发起对某静态文件的回滚请求，理由竟是它读取到了旧版本的配置并执行“保护性回滚”。简单来说：我们内部修复的有一个外部服务在悄悄把旧配置“修复回去”。最终解决方法是：
- 禁止该第三方在关键路径上的自动操作；
- 将关键文件迁移至受限域名并关闭第三方写入权限；
- 在部署后马上触发一次完整的端到端验证（包括第三方行为监控）。
结语与建议 如果你维护的是流量较大或更新频繁的网站，把缓存问题做成可观察、可回滚、可验证的流程会省下大量时间。我的经验总结成三句话：每层缓存都要知道它在哪里、谁在管理它、它的失效机制是什么。把部署自动化做成“带钩子”的流程（发布后自动校验、自动清理 CDN），并对外部服务加上权限和行为限制，会让你睡得更踏实。
如果你愿意，我可以把本文中的检查清单转成一份可下载的发布前核对表，或者帮你审一遍部署脚本和 CDN 配置。留言或私信我，我们把这事彻底堵死。