CFCF Static Export ProDOCS
首页/Cloudflare 文档/Cloudflare Durable Objects 中文文档

Cloudflare Durable Objects 中文文档

参照官方手册结构整理(数据截至 2026-10,配额/价格以官方最新页面为准)。技术术语保留英文原词。


1. 概述

Durable Objects(DO) 是 Cloudflare 的一种特殊 Worker,把计算与存储打包在一起,用于构建**有状态(stateful)**的无服务器应用。

一句话定位:强一致、带持久存储的状态协调原语——每个对象有全局唯一名字,可作为多个客户端的协调点。

Free 与 Paid 计划均可用。SQLite 存储后端已 GA,且在 Free 计划即可使用。


2. 核心概念

  • 全局唯一名字:每个 Durable Object 有唯一名,可从世界任何地方向特定对象发请求,用于多客户端协调(聊天、协作、游戏、实时通知)。
  • 持久存储:存储与对象在一起,因此强一致且访问快。
  • 单线程:单个对象本质单线程,单对象软上限约 1,000 请求/秒;可水平扩展出无限个对象。
  • SQLite 后端(推荐):用 sql.exec 等 Storage API 做事务化、强一致、可序列化的存储。
  • Alarms:可设定在未来某时刻触发对象执行计算(定时任务)。
  • WebSocket Hibernation:以极低开销管理大量客户端长连接。

3. 架构与工作原理

DO 像 Worker 一样就近自动部署、按需启动、空闲关闭,全球可有数百万个。但不同于普通 Worker:每个对象有名字 + 持久存储,因此能协调状态。DO 是 Worker 脚本,继承 Workers 的调用级 CPU 限制。


4. 快速开始(SQLite 后端)

wrangler.jsonc 配置类与绑定:

{
  "durable_objects": {
    "bindings": [{ "name": "CHAT", "class_name": "ChatRoom" }]
  },
  "migrations": [{ "tag": "v1", "new_classes": ["ChatRoom"] }]
}
import { DurableObject } from "cloudflare:workers";

export class ChatRoom extends DurableObject {
  async fetch(request: Request): Promise<Response> {
    const stmt = this.ctx.storage.sql.exec("SELECT count(*) FROM messages");
    return Response.json(stmt.one());
  }
}

5. 配额与限制(SQLite 后端)

限制项 Workers Free Workers Paid
Durable Object 类数 / 账户 100 500
存储 / 账户 5 GB 无限
单对象存储 1 GB 10 GB
单请求 CPU 时间 继承 Workers(10 ms) 默认 30 秒(可配至 5 分钟)
Key + Value 合计 ≤ 2 MB ≤ 2 MB
WebSocket 消息大小 32 MiB(仅接收) 32 MiB
同时外部连接 / 请求 6 6

SQL 限制与 D1 相同:每表列 ≤ 100、单行 ≤ 2 MB、SQL 长度 ≤ 100 KB、绑定参数 ≤ 100。


6. 定价

计费项 Workers Free Workers Paid
请求 100,000 / 天 含 100 万 / 月,超出 $0.15 / 百万
时长(Duration,GB-s) 13,000 GB-s / 天 含 40 万 / 月,超出 $12.50 / 百万 GB-s
SQLite 行读 500 万 / 天 含 250 亿 / 月,超出 $0.001 / 百万行
SQLite 行写 10 万 / 天 含 5000 万 / 月,超出 $1.00 / 百万行
SQLite 存储 5 GB 含 5 GB·月,超出 $0.20 / GB·月
  • 免费日限额每日 00:00 UTC 重置;超免费额直接报错,需升级 Paid。
  • 单对象存储满(Free 1 GB / Paid 10 GB)后写入失败(SQLITE_FULL),但读与删除仍可用。

7. 最佳实践

  • 用对象名做分片/路由(如 room:123),把协调粒度降到单对象。
  • 用 SQLite 后端替代旧 KV 后端(Free 仅支持 SQLite 后端)。
  • 单对象别做过多 list(),会拉低吞吐;必要时拆更多对象。
  • 需要高频定时任务用 Alarms,而非轮询。

8. 适用场景与选型

  • 多客户端协调:协作编辑、聊天、多人游戏、实时通知、AI Agent 状态。
  • 需要强一致的计数/锁/会话 → 选 DO(而不是最终一致的 KV)。
  • 简单全局小配置、读多写少 → KV 更轻;关系型 SQL 查询 → D1;大文件 → R2。