Cache

Tanplate 把“HTTP 响应缓存策略”和“Cloudflare KV 产品能力”分开管理。公开响应可以使用明确的 Cache-Control；KV 只有在有经过基准验证的消费者时才能启用。

KV 能力

默认 Manifest 配置为：

{
  "features": {
    "cache": {
      "consumer": null,
      "enabled": false,
      "evidence": null
    }
  },
  "providers": {
    "cache": "kv"
  }
}

启用时必须同时填写稳定 consumer 名称和 benchmark evidence 路径。Manifest 校验会拒绝“先开资源、以后再找用途”的配置；三环境 preflight 还会要求 Web 的 CACHE KV binding 与目标资源 ID。

Capability Profile 负责资源 inventory 和绑定门禁，不会自动生成业务缓存算法。消费者仍需定义 key、TTL、失效、版本和回源语义，并用测试证明关闭能力后没有运行时触达。

当前 HTTP 缓存

• 匿名 Projects 列表和详情使用短时公共缓存，登录态响应为 private, no-store。
• 公开 Project 媒体使用 ETag、Range 和共享缓存；受限媒体禁止缓存。
• Feed 与 robots 使用有限公共 TTL。
• Auth、Consent、Newsletter、User Assets、Developer API 和 AI 响应禁止共享缓存。

任何响应只要可能因 Session、owner、Consent 或授权而变化，就不能使用公共 cache key。缓存不得保存 Cookie、Authorization、email、token、私有对象地址或自由文本输入。

接入清单

1. 先用实际流量模型建立 benchmark evidence。
2. 在 Manifest 填写 consumer、evidence 并启用 Cache。
3. 运行初始化与三环境 preflight，确认 CACHE inventory。
4. 在单一领域 adapter 中实现 key/TTL/失效，不在多个 route 复制逻辑。
5. 覆盖命中、回源、失效、权限变化和关闭 Profile。

资源规划见 Cloudflare。