我把关键点核对了一遍 — 91大事件 — 关于缓存设置的说法 — 看完我沉默了三秒。我不下结论，但信号很明显

标题够煽，内容更要冷静。把“缓存设置”这件事从表面热闹拉回到数据与证据上，我逐条核对了关键点，针对那句广为流传的说法做了梳理。下面是我的观察、拆解和下一步可操作的方向——不强行得出终极结论，但给你看明白了为什么我会停顿三秒。

一眼看过去的三个常见模式

• 模式 A：TTL 极短或不一致。很多响应头看到 max-age 很短（几秒到几分钟），但静态资源并没有明显需要这么频繁更新的理由。这个信号通常意味着后端或部署脚本在“保守”缓存，带来额外请求与带宽浪费。
• 模式 B：头部冲突或互斥策略并存。比如同时存在 Cache-Control: no-cache 与 Expires 设置，或 ETag 与不稳定的 Last-Modified 搭配，浏览器与 CDN 之间的缓存判断逻辑被混淆，导致本可缓存的内容频繁走源。
• 模式 C：CDN 配置与源站不一致。源站允许长 TTL，CDN 端却配置了短缓存或频繁清理；反之亦然。结果是缓存命中率低、延迟高或出现“缓存抖动”。

我核对的关键点（逐项可复查）

1. 响应头一览（Curl/DevTools）

• 查哪些头被返回：Cache-Control、Pragma、Expires、ETag、Last-Modified、Vary、Age、Surrogate-Control、CDN 特有头（如 X-Cache）。
• 用 curl -I 或在 Network 面板里观察真实请求与重验证行为，注意 200/304/Hit/Miss 标签。

1. Cache-Control 的语义是否合理

• public/private、max-age、s-maxage、no-store/no-cache、must-revalidate、immutable、stale-while-revalidate 等是否被正确使用。
• public 与 CDN 的配合是否一致；s-maxage 对共享缓存（CDN）是否有明确值。

1. 缓存键与变体（Vary）

• Vary: Cookie/Accept-Encoding/User-Agent 等是否被滥用。过度使用 Vary 会导致缓存碎片化，命中率下降。
• Query string 是否被当作缓存键，是否存在无意义的查询参数导致缓存无法命中。

1. ETag 与 Last-Modified 的稳定性

• ETag 是否随每次部署或响应变化（导致 304 失效），或者服务器生成策略导致无意义改变。
• Last-Modified 是否反映资源真实更新时间；动态生成的时间戳会破坏重验证。

1. CDN 行为与源站策略

• CDN 是否在边缘做了额外的缓存策略或清理脚本？
• 是否有自动化部署/清缓存流程在每次发布时触发全站刷新？

1. 服务工作线程（Service Worker）与客户端缓存

• 是否存在 Service Worker 覆盖标准缓存逻辑，导致本应由 HTTP 缓存控制的资源被 JS 接管？
• 离线缓存策略是否与线上更新策略冲突？

1. 观测数据：命中率、延迟与流量

• 检查 CDN/监控面板上的缓存命中率、边缘命中与带宽趋势；短期内的波动能揭示配置问题或部署带来的副作用。
• 看时间序列图：是不是在某次发布后命中率骤降？还是在某些路径/资源类型上长期偏低？

这些信号合在一起告诉了我什么

• 单一头部问题往往不致命，但多项小问题累积就会放大：短 TTL + Vary 滥用 + ETag 不稳定 = 极差的缓存效果。
• 技术栈中不同层（源站、CDN、客户端脚本）若没有统一策略，缓存策略会被互相抵消或重复工作，最终成为“看似有缓存，实际上在走源”的假象。
• 某些所谓的“最佳实践”在具体场景下并不适用：例如 immutable 在频繁部署的静态资源目录下，如果没有版本化，反而造成更新不可见的问题。信号告诉我，很多团队在工程化和运营角度没把缓存当作产品来打理。

实操清单：我会先做的五件事

• 用 curl 批量抓取关键资源的响应头，建立基线报告（包含 200/304/Hit/Miss、Age）。
• 在 CDN 面板和源站分别核对 TTL、缓存键与清理策略，找出不一致的地方。
• 检查部署流水线是否在每次发布时触发全局缓存清理，评估是否有更细粒度的版本化替代。
• 审计 ETag/Last-Modified 的生成逻辑，优先采用内容指纹（文件哈希）做版本控制，避免无意义变化。
• 观察一周到一个月的命中率与流量趋势，确认改动带来的量化效果。

一句话总结（并非结论） 我不下结论，但把每个信号拼在一起之后，很难把这些现象解释成“偶然”。它们更像是系统设计与运营实践的磨合问题：每个小决定单独看都合理，合在一起就暴露出缺乏统一策略的后果。那三秒的沉默，是在把这些零碎的证据拼成一幅图之后，意识到问题不仅仅在某一个点，而是在流程与标准化的缺失。

如果你也遇到类似情况

• 想要一份可执行的缓存现状诊断清单，我可以帮你把 curl 输出、CDN 报表和部署流水线的行为一起梳理，给出优先级排序和短中长期修复计划。
• 如果只是想把这件事讲给团队听（非技术人员也能懂），我可以把关键发现做成一页要点 PPT，直观且能推动决策。

本文标签： # 我把 # 关键点 # 对了