有人发现了一个细节 - 91官网：关于缓存设置的说法｜我反复确认了两遍…线索都指向同一个答案
引子 最近在检查一个站点时，发现了一个看似微不足道但影响巨大的细节——缓存策略的实际表现和期待不一致。我把问题从浏览器端和服务器端分别检查了两遍，所有线索都指向同一个答案：问题根源在于源站响应头与资源版本管理不一致，导致浏览器和中间缓存（CDN）无法稳定命中缓存。下面把排查过程、证据和可执行的解决步骤分享出来，方便你快速定位并修复类似状况。
我怎么发现的（两次确认）
- 第一次：在浏览器（Chrome）里打开开发者工具，Network 面板里发现页面每次刷新都在重新下载大量静态资源，且每次请求都返回 200 而非 304。这说明缓存没有被正确利用。
- 第二次：用命令行工具(curl)直接请求，查看响应头。curl -I https://你的域名/路径 可以快速看到 Cache-Control、Expires、ETag、Set-Cookie、Vary 等关键头。结果显示：对静态资源要么没有明确的 Cache-Control，要么夹带了会影响缓存的响应头（例如 Set-Cookie、Cache-Control: no-cache），或者资源 URL 带有会频繁变化的查询字符串。 两次检查得出的结论一致：不是浏览器的问题，也不是 CDN 的任性，而是源站输出的响应头和资源管理方式在“主动”阻止或降低缓存命中率。
关键线索与它们说明的问题
- Cache-Control/Expires 缺失或设置不当：没有设置长缓存的静态资源会被频繁重新请求；把 HTML 设置为长期缓存会导致内容更新不及时。
- Set-Cookie 出现在静态资源响应中：带 Cookie 的响应通常会阻止 CDN/中间代理缓存这些资源（许多缓存策略默认对带 Cookie 的响应不缓存）。
- 资源带查询字符串或未版本化：当静态资源没有文件名指纹（hash）而使用查询参数进行变更时，一些缓存策略会认为每次请求可能不同，从而不稳定缓存。
- 服务器返回 200 而非 304：说明 ETag/Last-Modified 没有被正确配置或客户端没有发送 If-None-Match/If-Modified-Since，进一步说明缓存协商未生效。 这些线索合在一起指向同一个答案：源站对缓存控制的配置不一致或不合理，进而影响了浏览器和 CDN 的缓存行为。
实际可执行的修复清单（按优先级） 1) 明确分层缓存策略
- HTML（动态页面）：短缓存或协商缓存，例如 Cache-Control: no-cache, must-revalidate 或者 max-age=60。页面需要频繁更新时设置短生存期。
- 静态资源（CSS/JS/图片/字体）：长期缓存，例如 Cache-Control: public, max-age=31536000, immutable，并通过版本化文件名（hash）确保更新可控。 2) 给静态资源做版本化（推荐）
- 构建时把文件名包含内容哈希（app.abc123.js），每次内容变更就换新文件名。这样可以放心给静态资源设置超长 max-age。 3) 避免给静态资源返回 Set-Cookie
- 将静态资源托管到不带 Cookie 的子域（例如 static.example.com），或通过 CDN 配置剥离 Cookie。静态响应带 Cookie 会让大多数缓存变得保守或不缓存。 4) 让 CDN 配置与源站策略一致
- CDNs 通常可以选择“遵从源站缓存头”或“自定义覆盖”。如果源站头是可靠的，设为遵从；需要更复杂的缓存逻辑时，在 CDN 层面写规则并在部署时同步清理（purge）缓存。 5) 配置 ETag / Last-Modified（作为辅助手段）
- ETag 和 Last-Modified 有助于客户端发起协商请求，从而返回 304 而不是完整 200。两者任选其一即可，但 ETag 更精确。 6) 自动化清理与部署流程
- 每次发布时触发 CDN 的缓存清理或把版本化流程自动化，避免手动干预导致缓存不一致。 7) 使用工具验证并持续监控
- 工具：curl、Chrome DevTools、webpagetest.org、GTmetrix、Pingdom 等。重点查看 Cache-Control、Expires、Age、ETag、Vary、Set-Cookie、Server-Timing 等头。
- 示例检查命令：curl -I https://your.domain/path/asset.js 关注返回的 Cache-Control、Age、ETag、Set-Cookie 等字段。
常见坑与如何规避
- 坑1：把所有东西都设置长期缓存——HTML 不应该长期缓存（除非用严格的版本化机制和服务工作者来处理更新）。
- 坑2：用查询字符串做版本控制（?v=123），有些 CDN 不把带查询的请求缓存或需要额外配置。
- 坑3：静态资源放在带应用 Cookie 的同一域名下——把静态资源移到无 Cookie 的域或子域。
- 坑4：只在浏览器里看效果不够，必须同时从多角度验证（浏览器、curl、CDN 日志），否则容易误判。
快速排查流程（5 分钟版）
- 浏览器：打开 DevTools → Network → 勾选 Disable cache（关闭缓存）看首次加载再取消重载，观察是否返回 200 还是 304。
- 命令行：curl -I https://域名/资源路径，读取 Cache-Control、ETag、Set-Cookie。
- CDN：登录 CDN 面板，核对是否遵从源站头，并查看最近命中率或日志。
- 部署回滚测试：在变更后观察是否需要 purge，如果频繁 purge 说明版本化流程没做好。
- 性能测试：webpagetest/GTmetrix 运行后查看请求时间和缓存命中数据。
结论 当多个检查手段都指向同一个结果时，通常不是工具的误报，而是源站配置的问题。把缓存策略分层、对静态资源实行文件指纹化、避免在静态响应中带 Cookie、并让 CDN 与源站策略协同工作，能把缓存命中率和页面性能同时拉上去。小小的响应头，往往决定用户每次加载页面时要不要重下载几十甚至几百 KB 的资源——修好这些，体验和带宽成本都会显著改善。