Cloudflare 存储的一致性强弱，对代码意味着什么？

我本地用 20 个并发请求给 KV 计数器做“读、加一、写”，结果是 1。不是 KV 坏了，是我的代码默认了“读到的就是最新的”。

强一致的存储允许你写“写完立刻读”的直线逻辑，最终一致的 KV 要求你的代码对旧值免疫：读到旧值只能造成短暂陈旧，不能造成错误。

判断方法很简单，但要落到具体的数据和具体的写入频率上。下面几个问题，就是我给一份数据挑存储时的顺序。

哪些存储是强一致，哪些不是？

按官方文档的描述：R2 的上传、元数据更新、删除和 list 都是立即生效、对所有客户端可见的强一致；Durable Objects 强一致、事务性；D1 的主库也属于强一致这一侧。KV 是最终一致，变更在其他位置可见可能要“60 秒或更久”。

R2 有两个例外要记住：API key 的权限变更是最终一致，最长约一分钟；自定义域名前面的缓存，可能让删除或覆盖的对象继续被旧内容服务，甚至缓存 404。直连 Worker 绑定和 S3 API 读的是桶本身，不受缓存影响。

一份数据能不能放进 KV？

问一句：如果读到一分钟甚至更久之前的值，会怎样？

• 会让用户看到错误金额、重复扣减或权限误判，这份数据就不该放在 KV。
• 功能开关、站点配置、渲染好的页面片段，晚一分钟甚至更久生效通常无伤大雅，用 KV 换来的是全球就近读取的低延迟。

具体选型可以回到 Cloudflare 的四个存储产品该怎么选？，KV 自己的边界见 Cloudflare KV 能当数据库用吗？。

写入热点会把你推向哪里？

另一个常被忽略的维度是写入频率。官方限额里，KV 同一 key 每秒 1 次写入，R2 同一对象名每秒 1 次写入。这意味着它们不适合当作高频更新的共享状态。

高频更新的共享状态，天然属于单点串行的 Durable Objects。

本地测试能看出这些问题吗？

看不全。KV 同一 key 每秒 1 次写入的限制，我本地连续写同一个 key 全部成功，没有复现。所以本地测试通过，不代表线上不会被拒。

本文的并发计数结论在本地 wrangler dev 上跑过。其余限额与一致性行为以 2026-10 官方文档为准，我没有在线上验证；本地模拟复现不了跨地区传播延迟，同一 key 的写入限流本地也不会触发。限额会变化，以官方文档为准。官方参考：R2 一致性模型、KV 如何工作。