Cloudflare 的多个存储怎么组合，才不会出一致性事故？
“所有东西先塞进 KV”是我见过最常见的起点，但真实系统几乎都是几个存储拼起来的。拼法错了，事故不是出在性能上，而是出在两份数据对不上。
组合的原则只有一条：每一份数据只有一个权威来源，其他位置都是可重建的派生缓存。 KV 里缓存的页面可以丢，D1 里的订单不能丢。
这条原则能避免绝大多数一致性事故，还让演进成本变得很低。下面看常见的组合长什么样，以及它们是按什么顺序长出来的。
常见的组合长什么样？
D1 存业务记录，R2 存附件，KV 存配置和渲染缓存，Durable Objects 负责实时协调或限流。
R2 没有查询能力，所以索引和元数据放 D1，文件本体放 R2，是常见的搭配。
存储应该按什么顺序引入？
典型路径是：
- 早期用 D1 加 R2 覆盖大部分需求；
- 出现读热点时，在前面加 KV 或 Cache 做派生缓存；
- 出现需要强协调的实时功能时，再引入 Durable Objects。
由于每份数据只有一个权威来源，增加缓存层不会改变正确性，只改变新鲜度。
反方向的迁移为什么难？
把原本放在 KV 的权威数据迁到 D1 或 Durable Objects，需要同时处理写路径与旧值清理。所以一开始就别让 KV 成为权威来源。
选型的完整判断，见 Cloudflare 的四个存储产品该怎么选？。
本文的组合原则和演进路径是我的做法，没有在线上验证过；涉及的产品行为以 2026-10 官方文档为准，限额与行为会变化。