HTTP 压缩选择的是施加了内容编码的表示，不是一种新的媒体类型。经过 gzip 的文本，解压后仍然是文本。因此有效验证需要回答三个问题：编码是否可接受、传输内容是否变小、解码后是否恢复了原本要提供的字节。配置里勾选了压缩，或者接口返回成功状态，都不能同时证明这三件事。 分别检查编码可接受性、传输内容字节与解码后字节一致性。已记录的排除条件失败仍然是失败。 区分缺失、排除与偏好 根据 RFC 9110，Accept-Encoding 缺失时，任何内容编码都被认为可接受；显式空值则表示不希望使用内容编码。identity 代表没有内容编码，通常默认可接受，除非被 identity;q=0 或适用的 *;q=0 排除。通配符还可以让没有逐个列出的编码成为可接受候选，因此“只能发送客户端单独点名的编码”并不是完整规则。 ...
源站定义存储和新鲜度策略，缓存判断已保存的响应是否能满足下一次请求。无法直接复用时，验证器可以降低检查成本。这是几个相互独立的决定：在一次成功响应中找到 Cache-Control 和 ETag，并不能证明下一次请求会按预期执行。验收必须沿着重复请求继续观察，才能区分直接命中、成功验证和完整替换。 验证器检查已存表示是否仍然匹配。304 更新元数据，而缓存保留已有正文。 允许谁复用、可复用多久 private 把存储范围限制到单用户缓存，public 在其他条件允许时明确授予缓存许可。max-age 提供新鲜度寿命，s-maxage 则为共享缓存覆盖这个值。no-cache 允许保存，但要求每次复用前成功验证；no-store 禁止 HTTP 缓存存储，并不管住所有应用日志或用户保存的文件。这些指令都不能替代授权检查和传输安全，不能因为缓存头正确就省略访问控制。 对于带内容指纹的资源，如果字节变化一定带来新网址，public, max-age=31536000, immutable 可以是合理策略。这里的时长是一年，不是一个月。稳定网址下会变化的文档，应按更新要求选择策略：短寿命搭配验证器，允许有界的直接复用；no-cache 则要求后续每次 HTTP 缓存复用都先验证。两者的网络请求成本和可见更新延迟并不一样。 验证器回答另一个问题 客户端可以在 If-None-Match 中带回 ETag。条件 GET 的标签匹配时得到不含正文的 304；标签不匹配时，通常得到包含当前表示的 200。If-None-Match 使用弱比较，因此弱标签同样可以用于缓存验证。Last-Modified 支持 If-Modified-Since，但秒级时间戳可能遗漏快速连续变化。请求中只要存在 If-None-Match，就忽略 If-Modified-Since，而不是等标签匹配失败后再用日期兜底。 ...
在选择重定向或错误状态前，先检查方法、Location 头与缓存行为。
只有当 206 响应的边界与总大小描述了实际返回的字节时才有意义。
一次把方法边界搞清楚，OPTIONS、HEAD 与幂等写入就不再是意外。
条件请求是缓存的第二个时钟；304 意味着存储的副本仍是答案。
分开测试压缩与未压缩请求，让缓存和验证器描述实际送达的字节。
把浏览器端新鲜度与源站校验分开，再验证实现两者的响应头。