这事越传越离谱，91大事件 ｜ 关于缓存设置的说法 ｜ 结果下一秒就反转。据说后面还有更大的反转
这事越传越离谱，91大事件 | 关于缓存设置的说法 | 结果下一秒就反转。据说后面还有更大的反转
一、事件回放（简化版）
- 起因：有人发现网站显示旧内容，用户抱怨“内容更新后仍然看到旧页面”，于是把原因指向“缓存设置错误”。
- 扩散：社群中流传说法越来越绝对，责任人、指标、解决步骤都被口口相传，信息失真放大。
- 反转一：进一步排查后发现，问题并不在浏览器缓存，而是CDN在做版本回滚导致的缓存回填，实际触发点是一次自动化回滚。
- 反转二：深入日志后发现，触发回滚的并非代码BUG，而是监控误报（阈值设定过敏）和部署脚本在短时间内重复触发了清理/回滚动作。于是最初的“缓存设置”成了替罪羊。
- 最后：真正的教训是——单一指标容易误导决策链，多个系统相互作用才会造成复杂故障。
二、关于“缓存设置”的那些事实（拆开讲，别被表象带跑） 缓存并不是“万能的坏人”或“万恶之源”。缓存是性能优化的关键组件，但配置不当、监控策略和自动化脚本配合不好，才会产生事故链。常见的误区包括：
- 把HTML和静态资源（图片、JS、CSS）同等对待：HTML应短缓存或使用协商缓存（ETag/Last-Modified），静态资源适合长缓存并配合版本化。
- 忽视CDN失效与回滚机制：CDN缓存有自己的回收和回滚逻辑，发布策略要考虑到缓存失效窗口。
- 单靠浏览器刷新解决一切：用户端强刷或清缓存能解决部分情况，但不应该成为应急指导口径。
三、快速核查清单（遇到“缓存问题”先做这几步）
- 用 curl 查看响应头：curl -I https://your.site/path
- 关注 Cache-Control, Expires, ETag, Last-Modified, Age, Vary
- 在浏览器开发者工具的 Network 面板观察请求与响应头、是否从 service worker 或缓存命中。
- 检查 CDN 控制台：查看最近的 purge、回滚、规则变更记录与时间线。
- 查看部署流水线与监控告警时间点：是否有回滚/重试/自动化脚本在同一时间触发。
- 审核日志：应用日志、CDN 边缘日志、负载均衡器与监控系统的报警日志，再把时间轴拼起来。
- 用 A/B 或灰度回滚验证：把怀疑配置只在小范围放开观察，而不是直接全量变更。
四、实用配置建议（常见适配场景）
- 静态资源（带版本号的文件，如 app.v1.2.3.js）：
- Cache-Control: public, max-age=31536000, immutable
- 动态 HTML 页面：
- Cache-Control: no-cache, must-revalidate
- 或使用短期缓存，如 Cache-Control: public, max-age=60，然后配合 ETag/Last-Modified
- CDN 与缓存失效策略：
- 发布静态资源时使用文件名版本化，避免实时 purge
- 对于必须 purge 的变更，优先精确路径 purge，而非全站 purge
- 错误容忍性与降级：
- 使用 stale-while-revalidate 和 stale-if-error，能在上游不可用时保持可用性
五、组织与流程层面的防护
- 部署回滚的触发条件要有审批或二次确认，避免监控噪声造成连锁反应。
- 建立发布回滚的时间轴和责任链，出问题时能迅速定位谁在什么时间点做了什么。
- 把监控告警做到分级：告警不等于自动回滚，先人工确认再自动化响应（或至少引入冷却期）。
- 日常演练：定期进行小范围的发布/回滚演练，验证 CDN、缓存策略和监控联动是否如预期。