摘要

  • Cache-Groups 只有在同一个缓存里、组字符串逐字且区分大小写相同、响应又属于同一 URI 源时，才建立组关系。
  • Cache-Group-Invalidation 只是非安全请求响应中的本地可选信号；它不会级联，更不会自动同步其他缓存。

一次商品状态更新，可能同时让详情页、列表页和摘要接口里的旧响应失去效用。三者 URI 不同，缓存键也不同。RFC 9875 没有把它们说成同一个对象，而是提供两个标准字段，让缓存明确知道哪些已存响应存在一层可用于失效处理的关系。

第一个字段是 Cache-Groups。它采用 Structured Fields 的字符串列表。组名对缓存是不透明的：缓存只比较字符，不能从名称里推断层级、业务含义或权限。列表顺序没有意义，未知参数要忽略。实现至少要支持一个字段中的 32 个组，每个成员至少 32 个字符，但仍受 HTTP 字段总长度约束。

组关系有三个同时成立的条件。两个响应必须实际存放在同一个缓存；必须带有完全相同、区分大小写的字符串；还必须属于同一 URI 源。另一个源使用相同的 catalogue，不会加入这个组。另一个缓存碰巧保存同名标签，也不会与前一个缓存共享组状态。

第二个字段 Cache-Group-Invalidation 出现在可能改变状态的请求响应中，例如 POST、PUT 或 DELETE。它列出接收缓存可以失效的组。若同一字段出现在 GET 这类安全方法的响应中，缓存必须忽略。审计时不能只摘出字段值，还要保留触发它的请求方法和完整响应上下文。

标准使用的是 MAY。缓存可以把失效扩展到同组成员，也可以处理非安全请求响应里的组信号，但 RFC 9875 并没有要求所有缓存统一执行。RFC 9213 所定义的定向缓存控制可以对特定缓存类别加强要求；这是一层额外策略，必须单独证明其配置和适用范围。

“失效”也不一定等于删除字节。RFC 9111 允许缓存删除匹配的已存响应，或把它们标记为无效，要求再次使用前进行强制验证。因此，一条“已失效”回执还没有说明旧对象是否仍在存储、后续验证是否成功，或新内容是否已经填入。

组关系不会沿图传播。A 与 B 共享一个组，B 又与 C 共享另一个组，并不意味着通过第一个组失效 A 时可以穿过 B 自动失效 C。RFC 9875 明确禁止这种级联。实际候选集合取决于该缓存在处理时刻保存了哪些成员。

最大的边界是拓扑。机制只在单个缓存内、同一源的已存响应之间运行，不负责层级或网状结构中的多缓存同步，也不连接不同源的响应。一个边缘节点收到信号，并不能证明另一条路径上的节点收到、理解或执行了相同行为。

因此，“清除完成”必须拆成证据链：源站状态变化；谁有权发出或保留字段；请求方法与响应；每个中间节点是否收到；是否支持 RFC 9875；采用哪项本地或定向策略；当时有哪些组成员；作出何种失效决定；删除还是标记；之后验证或重新填充得到什么；以及每条重要用户路径上的应用探针结果。

共享源还带来权限风险。RFC 9875 提醒，多个主体共用一个源时，其中一方可能把自己的资源与另一方的资源编到同组，或发出影响对方的信号。平台必须按租户和源控制字段注入权，而不能把它当成普通的自由响应头。

IANA HTTP 字段名登记表 把两个字段登记为永久 List。这证明名称和规范引用已经统一，不证明某个现网产品支持、某条链路保留、某次处理已经执行，更不证明用户看到了更新。

来源