KV

适用场景

KV 适合公开配置、功能开关、接口响应缓存、公开目录、静态索引和清单文件。接口响应缓存的前提是允许短时间旧数据；公开目录、静态索引和清单文件可以在构建期或后台任务写入。

用户低频偏好可以放 KV，但权限撤销要走 D1 或 Durable Objects。登录会话不优先放 KV。评论、订单、文章关系数据交给 D1；计数器、库存、排行榜交给 Durable Objects 或 D1；文件、图片、大对象交给 R2。

成本和一致性

读取要减少散读，能合并就合并成清单。写入适合低频后台任务；评论、订单、计数器和状态流走 D1 或 Durable Objects。用户请求路径避免扫描命名空间，分页和筛选交给 D1。大对象、附件和图片进 R2。

KV 付费后也不会把同键高频写入变成强项。权限撤销、订单确认、库存和锁需要 D1 或 Durable Objects。

排查项

• 不要把 KV 当强一致数据库。其他地区可能短时间读到旧值；权限撤销、库存、订单确认用 D1 或 Durable Objects。
• 不要同一个键高频写入。超过每秒 1 次写入会失败；需要拆键，或用 Durable Object 集中写入。
• 不要每个请求读多个散键。这样会消耗 Free 读额度；配置尽量合并，预生成清单。
• 不要在用户请求里列举全部键。列举操作单独计费，查询和分页交给 D1。
• 不要把附件塞进 KV。体积、成本和读取方式都不合适；R2 存文件，D1 / KV 存索引。
• 本地、预览、生产不要共用命名空间，按环境拆开。

产品对比

目标	更适合的能力
读多写少配置、缓存、公开索引	KV
关系查询、排序、筛选、事务	D1
文件、图片、附件、大对象	R2
单实体强一致、写冲突、连接状态	Durable Objects
异步更新缓存、削峰、重试	Queues
HTTP 层缓存	Cache Rules / CDN Cache