群里突然炸了 ｜ 91大事件 ｜ 关于缓存设置的说法｜关键点居然在这里！！现在的问题是：到底哪里变了

群里突然炸了 | 91大事件 | 关于缓存设置的说法｜关键点居然在这里！！现在的问题是：到底哪里变了

前言：事情回顾（1分钟速读） 群里一阵炸锅：网页、资源或接口“突然变了”——有人看到旧版页面被缓存，有人看到新版但图片还是老的。大家开始讨论缓存设置，观点五花八门。作为过来人，我把能想到的所有可能性和排查、修复步骤整理成一篇，帮你快速定位“到底哪里变了”，并给出可立即执行的解决方案与长期防护建议。

一、先说结论（快速应对）

• 立刻在浏览器 DevTools 的 Network 面板勾选 Disable cache，并在不同网络/设备强刷一次，看问题是否消失。
• 用 curl 检查响应头：curl -I https://your.site/path
• 如果是 CDN（如 Cloudflare、Fastly）或反向代理（如 Nginx、Varnish），先做一次手动或 API 清理（purge）缓存，观察是否恢复。 这些步骤能快速判断问题是“本地浏览器缓存”还是“服务器/中间层缓存”。

二、缓存体系一张图（理解问题所在） 现代网站的缓存不是单一层级，常见的几层：

• 浏览器缓存（Cache-Control、Expires、ETag/Last-Modified）
• Service Worker 缓存（可完全绕过或覆盖浏览器规则）
• CDN/边缘缓存（Cloudflare、Akamai、Fastly 等）
• 反向代理缓存（Nginx proxy_cache、Varnish）
• 应用层缓存/内存缓存（Redis、Memcached） 变了，通常是其中一层的配置或数据发生了变化，导致缓存策略与预期不一致。

三、常见触发场景（哪里可能被改了）

• 部署改了 header：Cache-Control、Vary、ETag、Last-Modified 被不小心修改或移除。
• 构建流程改了文件名策略：从 content-hash 文件变成固定名，没做版本化。
• CDN 配置变更：缓存规则、路由规则、缓存 TTL 或分区发生变动。
• Service Worker 被更新或失误代码导致旧资源一直被拦截并返回缓存版本。
• 反向代理/负载均衡策略改变，导致请求走到不同缓存池（一个池旧内容未清理）。
• 时间同步或服务器时间错误，导致 Expires/Last-Modified 计算错误。
• 客户端误操作：用户/群里的人用了插件或代理导致缓存被“锁住”。

四、实战排查步骤（从快到细） 1) 本地快速确认

• 在浏览器 DevTools → Network 勾选 Disable cache → F5 强刷。若问题消失，问题偏客户端缓存/Service Worker。
• DevTools → Application → Service Workers，检查是否存在 service worker 拦截并返回缓存。卸载或更新 service worker 试试。

2) 检查响应头

• curl -I https://your.site/path
• 关注 Cache-Control、Expires、ETag、Last-Modified、Age、Surrogate-Control（部分 CDN）、Vary 示例： HTTP/1.1 200 OK Cache-Control: public, max-age=86400 ETag: "abc123" Age: 3600 Age 表示资源在中间缓存里已经存在多久；若 Age 很大，说明中间层在服用旧缓存。

3) 比较“好”与“坏”请求

• 在不同网络或机器上抓一次头，比较差异。
• 用 curl -I --header "Cache-Control: no-cache" 强制回源（部分 CDN 会忽略这项，但可测试）。

4) 查看 CDN/代理面板

• CDN 的缓存规则、Page Rules、Edge Cache TTL、Cache Everything 等设置是否被改过？
• 查看最近的配置变更记录与 purge 操作。

5) 检查部署/构建

• 最近的构建有没有改变静态资源命名（去掉 hash）？
• CI/CD 有没有改动到静态文件上传或上传路径，导致旧资源仍在边缘节点。

6) 服务器时间与签名

• 时间不同步会影响 Expires / Signed URL 的有效期，检查 NTP 状态。

五、常见问题与对应快速修复

• 问题：CDN 缓存的是旧文件 快修：在 CDN 面板执行 purge（按文件或按路径）或修改资源 URL（版本号 / filename.hash.js?v=TIMESTAMP）。
• 问题：浏览器显示旧资源，DevTools 无效 快修：检查并 unregister service worker；指导用户 Ctrl+F5 或清浏览器缓存。
• 问题：API 返回老数据 快修：检查反向代理缓存规则，临时设置响应头 Cache-Control: no-store 或在代理层清缓存。
• 问题：不同用户看到不同版本 快修：检查 Vary 头（尤其是 Cookie、Accept-Encoding、User-Agent），以及是否存在流量路由到不同后端集群。

六、修复建议（短期 vs 长期） 短期（立刻做）

• 在影响最小时间窗口内执行 CDN purge 或临时降低缓存 ttl。
• 如果涉及动态接口，短期返回 Cache-Control: no-store 或 max-age=0 并携带正确的 Vary。
• 通知群内：说明已采取措施与预计恢复时间，避免重复操作。

中期（本周内）

• 修复坏的构建或部署脚本，恢复资源版本化策略（hash 文件名）。
• 修订服务端响应头策略，明确静态资源长期缓存、HTML/接口短期或不缓存。
• 针对 Service Worker，增加严格的版本控制与回退策略。

长期（防止复发）

• 建立变更日志与配置审计：任何 CDN/代理规则变更都应通过审批。
• 自动化缓存失效：构建完成后触发 CDN purge 或上传带 hash 的文件并更新 HTML 引用。
• 增加监控：监控 200 返回的 Age 值异常、Cache-Control 头异常、异常的客户端报错率与用户版本分布。
• 测试环境加入端到端缓存链路测试，预演缓存配置变更对线上影响。

七、举个真实小案例（快速感受） 某次项目把静态资源构建从带 hash 的文件名改回 index.js（为了兼容某旧系统），同时忘记在部署脚本中触发 CDN purge。结果一部分用户访问到新版 HTML，但引用的 index.js 在 CDN 上仍是旧版。表现是“页面结构变了，但功能还是旧的”。解决：回滚构建改动并触发 purge；紧接着改回文件名 hash 策略和 CI 自动 purge 流程，防止再次发生。

八、沟通模板（发群用，简短明确） “目前排查发现是 XXXX（比如：CDN 缓存未清理 / service worker 拦截）。已在做的动作：1) 已触发 CDN purge；2) 要求用户强刷或清 Service Worker；3) 本周修复构建脚本并加自动化 purge。预计恢复时间：30 分钟内。后续会把原因与防范写成文档发到群里。”

结尾：哪里变了？基本上是“缓存链路的某一环发生了配置或部署上的改动”，定位关键在“把缓存链路每一层的响应头和配置挨个核对”。按上面步骤走一遍，通常能在短时间内定位并恢复，同时把问题变成改进点，避免下一次群里再炸。