HTTP 缓存，是客户端与服务器的契约

缓存策略应该跟着资源语义走

资源可分成两类：内容寻址的静态文件和稳定 URL 的动态内容。哈希文件名一旦发布便不再改变，适合长期缓存；首页地址不变但内容更新，适合短缓存或重新验证。为所有响应统一设置一年缓存，会让一次简单的文案修正变成用户侧排障。

三个指令不要混淆

no-store 要求缓存不要存储响应；no-cache 允许存储，但复用前必须向服务端验证；max-age 定义响应保持新鲜的秒数。private 允许浏览器缓存，但禁止共享缓存存储。对于私人账户页面，可根据威胁模型使用 private, no-store，同时明确 CDN 不应缓存带认证的接口。

ETag 解决是否变化的问题

服务端返回 ETag 后，客户端可以用 If-None-Match 发起条件请求。若表示没有变化，服务端返回 304，客户端复用已保存的响应体。ETag 是不透明标识，不保证等于 MD5。强 ETag 表示字节级一致，弱 ETag 允许语义等价；断点续传等场景对验证器还有更严格的要求。

curl -i https://example.com/article/
# 将真实响应的 ETag 原样带入，不自行猜测
curl -i -H 'If-None-Match: "observed-etag"' https://example.com/article/

Vary 是缓存键的一部分

同一个 URL 如果因 Accept-Encoding 返回不同压缩表示，应通过 Vary 表达这一差异。若内容因语言而变化，可使用 Vary: Accept-Language，但组合过多会降低命中率。不要无边界地按 Cookie 分裂缓存；对于个性化内容，通常显式禁止共享缓存比依赖一个复杂缓存键更安全。

发布之后如何核验

用无条件请求确认响应体与制品摘要一致，再用条件请求确认验证器行为。查看 Age、Cache-Control、ETag 和 CDN 的命中状态，但不要仅凭一个 HIT 判定正确。HTTP HEAD 不返回响应体，不能证明内容是新版本。排查时应分别测试源站与 CDN，避免把边缘缓存问题误诊成部署失败。