摘要

  • HTTP 新鲜度取决于当前缓存年龄与新鲜期的比较，Age 字段本身并不包含完整判断。
  • 可复核的缓存决策必须同时记录时序、有效指令、验证结果、过期服务权限和实际交付内容指纹。

设想运维看板读到一份缓存配置的 Age: 20，便将它标成绿色。二十秒看起来很短，但响应同时带有 max-age=10；源站不可达时，缓存依照某项过期服务许可继续返回这份内容。Age 数值可以完全正确，看板的“仍然新鲜”结论却是错的。

RFC 9111 将“当前缓存年龄”和“新鲜期”分开定义。响应的缓存年龄尚未超过新鲜期时才算新鲜，超过后即为过期。真正的判断是 freshness_lifetime > current_age。一个 Age 值既没有给出适用的新鲜期，也没有独自呈现当前缓存年龄的完整计算过程。

新鲜期还有明确的优先顺序。共享缓存首先采用 s-maxage，随后可能采用 max-age，再后是 Expires 与 Date 的差值。没有显式过期时间时，缓存只在规定条件下采用启发式期限。标准没有规定唯一算法，因此两个合规部署可能对同一元数据计算出不同期限。

Age 自身也是估算结果。它表示源站生成或成功验证响应以来的秒数，可能合并收到的 Age、请求到响应的时延、响应时间与 Date 的差异，以及响应在当前缓存中的驻留时间。缓存未经验证而复用存储响应时，必须发送其计算出的当前年龄。

这使 Age 成为重要证据，却不是裁决。二十秒面对六十秒寿命时是新鲜的，面对十秒寿命时已经过期。过期也不必然等于违规：缓存断开连接或得到明确许可时可以服务过期响应，但 no-cache、must-revalidate 等适用指令可以禁止这种行为。协议允许返回过期内容，并不代表价格、权限、配置或撤销状态在业务上仍可接受。

因此应建立“新鲜度决策收据”。这是编辑工作为组织证据而提出的控制方法，并非 IETF 或 RFC 9111 定义的协议元素。它关联缓存身份与配置、请求目标、存储响应标识和交付摘要；保存 Date、收到与发出的 Age、请求时间、响应时间和驻留时间；标明新鲜期来自 s-maxage、max-age、Expires 还是具名启发式规则；再记录有效指令、验证请求与结果、过期服务授权以及最终决定。这样才能重现复用原因，而不是把一个可见数字当成证明。

来源