#1. Workers KV：全网公告栏
KV 最像驿站系统里的公告栏。
你把公告先贴到中心存储，之后各地驿站会把常看的内容缓存下来，所以：
- 读非常快，尤其热读
- 写不是“全球瞬时强一致”
- 更适合读多写少
适合：
- 配置中心
- Feature Flag
- 地区化文案
- 用户偏好
- 缓存结果
- 黑白名单
不适合：
- 高频更新单个键
- 强事务
- 计数器抢写
- 库存扣减
一句话记忆：
KV 是“读多写少的公告栏”，不是“强一致的银行柜台”。
#2. R2：边缘宇宙的大仓库
R2 是对象存储，像驿站体系外接的大仓库。
它适合放：
- 图片
- 视频
- 压缩包
- 用户上传文件
- 模型文件
- 导出报表
- 日志归档
R2 的关键心智：
- 面向对象，不是面向 SQL 行
- S3 兼容
- 强一致
- 适合大对象和文件流
- 读流量大的场景很友好，尤其官方强调无 egress fee
一句话记忆：
R2 管的是“箱子”，不是“账本”。
#3. D1：轻关系账本
D1 是 Cloudflare 的 serverless SQL 数据库，走的是 SQLite 语义。
它特别像驿站里的账本柜台：
- 能写 SQL
- 有关系查询能力
- 很适合中小规模业务数据
- 官方文档强调它适合横向拆成很多小库，典型是每用户、每租户、每实体一个库
这点非常重要。D1 的思路不是“永远往一座无限大的超级库堆”，而是：
把宇宙拆成很多可管理的小星球账本。
适合：
- SaaS 多租户
- 内容系统
- 订单/工单元数据
- 中后台业务表
- 页面驱动型关系查询
不适合：
- 超重 OLTP 的单库怪兽想象
- 你明明需要超高并发全局写协调，却硬塞进单个关系表
#4. Durable Objects：唯一协调室
这是 Workers 世界里最容易让人“突然开窍”的能力。
Durable Object 可以理解成：
某个逻辑实体在全球范围内唯一的协调室，里面有一个单线程值班官和它自己的私有强一致存储。
比如：
- 一个聊天室一个 DO
- 一个文档一个 DO
- 一场比赛一个 DO
- 一个商品库存协调器一个 DO
- 一个租户的限流器一个 DO
Cloudflare 官方文档里最核心的心智有两个：
- 每个 DO 有全局唯一名字/标识
- 它把计算和存储放在一起，而且是强一致的
这意味着很多传统系统里要靠分布式锁、悲观锁、抢占 CAS 才做得稳的事情，在 DO 里可以换成“把同一原子的请求都路由到同一个房间”。
不是大家一起抢银行柜台，而是同一类业务统一去一个号窗排队。
一句话记忆：
Durable Objects 不是缓存，它是“有脑子、有私账本、会排队”的唯一房间。
#5. Queues：传送带和缓冲区
Queues 像驿站里的传送带。
主请求不该在柜台前做的慢活，都应该丢到传送带后面，比如：
- 发邮件
- 生成缩略图
- 写审计日志
- 调第三方 API
- AI 摘要/分类/打标
- 批量入库
它的价值不只是异步，更是：
- 削峰
- 重试
- 批处理
- 解耦
一个特别关键的官方事实是：
Queues 强调可靠送达，但不保证消息按发布顺序交付给消费者。
所以你拿它做“必须严格顺序”的金融流水串行器，就走错路了；那类事通常更像 DO 的活。
一句话记忆：
Queues 是“传送带”，不是“顺序绝对严格的单线程窗口”。
#6. AI Gateway：AI 总闸门
AI Gateway 最像 AI 请求世界里的总闸门和海关。
它不是模型本身，而是 AI 流量治理层。官方文档强调的能力包括：
- Analytics
- Logging
- Caching
- Rate limiting
- Retries
- Fallback
- Dynamic routing
- Guardrails / DLP / BYOK 等治理能力
如果你直接把业务请求打到模型厂商，相当于每个驿站都私自出海。
如果你先过 AI Gateway，就像所有船都先过总闸门：
- 先验身份
- 先做观测
- 先做限流
- 先看能不能缓存
- 某个模型故障就切备份航线
一句话记忆：
AI Gateway 管的是“AI 流量秩序”，不是“模型推理本体”。