本文基于 Cloudflare 官方文档（cloudflare-docs@production，数据截至 2026-10）系统整理，并用更贴合中文读者认知的结构重新组织。所有配额、限制与价格均来自官方 Limits / Pricing 文档，文末附来源。价格可能随官方调整，请以最新官方页面为准。

引言：一套无服务器的边缘技术栈

Cloudflare 开发者平台把「计算、数据库、对象存储、键值存储」做成了一系列无需管理基础设施的产品，全部运行在其全球边缘网络上。它们彼此之间通过 Bindings（绑定） 用几行代码即可连通，组合在一起就能搭建完整的应用。

这四者是 Cloudflare「存储 + 计算」组合里最常被一起使用的核心。下面逐一展开。

一、Cloudflare Workers —— 无服务器计算

1.1 产品定位

Workers 是 Cloudflare 的无服务器计算平台：你写代码，用一条命令部署到其全球网络，无需管理服务器、无需复杂配置。它适合构建前端应用、后端 API、AI 推理、定时任务等几乎任何类型的程序。

1.2 核心特性

• 边缘执行：代码运行在 Cloudflare 全球节点，离用户更近，延迟低、可靠性高。
• 多语言：原生支持 JavaScript / TypeScript / Python，Rust 等可通过 WebAssembly 运行；并兼容 React、Vue、Svelte、Next、Astro 等框架。
• 智能放置（Smart Placement）：可让 Worker 自动靠近其依赖的数据源（如数据库）以降低延迟。
• 丰富的集成：通过 Bindings 直连 D1、KV、R2、Durable Objects、Queues、Vectorize、Workers AI、Hyperdrive 等。
• 可观测性：内置实时日志与流量分析。
• 免费起步：灵活计价，任何规模都负担得起。

1.3 工作原理与关键概念

• V8 Isolate 模型：Workers 运行在 V8 隔离（isolate）中，而非传统容器/虚拟机。每个 isolate 启动极快（毫秒级），多租户共享同一进程的内存，这就是它冷启动几乎无感的根本原因。每个 isolate 内存上限 128 MB。
• 事件驱动：一个 Worker 本质是一个监听事件的处理器，最常见的是处理 HTTP 请求（fetch 事件）。
• 触发器（Triggers）：除了 HTTP 请求，Workers 还支持 Cron 定时触发、Queues 消息消费、Durable Objects、Email 等触发方式。
• Bindings（绑定）：把外部资源（数据库、存储桶、KV 命名空间等）「绑」到 Worker 上，在代码里通过 env.XXX 直接访问，无需管理密钥与连接池。
• Wrangler：官方命令行工具，用于初始化、本地开发、部署 Worker 项目以及管理 D1/R2/KV 等资源。
• CPU 时间 vs 挂钟时间：CPU 时间只统计真正执行代码的时间；await fetch() 等网络等待不计入 CPU 时间。

1.4 典型场景

• 把现有站点/API 包一层边缘逻辑（鉴权、改写、A/B）。
• 全栈 Web 应用（配合前端框架 + 存储产品）。
• 定时任务（Cron）、后台作业（Queues / Workflows）。
• Serverless AI 推理（Workers AI）、边缘无头浏览器（Browser Run）。

1.5 配额与限制

其他硬性限制：

• URL ≤ 16 KB；请求头 ≤ 128 KB；响应头 ≤ 128 KB；响应体无强制上限。
• 请求体大小取决于主账户计划：Free/Pro/Business 为 100 MB，Enterprise 最高 5 GB。
• CDN 缓存对象上限：Free/Pro/Business 512 MB，Enterprise 5 GB。
• Cache API 单次请求调用次数：50（Free）/ 1,000（Paid），与 fetch 子请求共享配额；缓存对象最大 512 MB。
• 每请求日志数据上限 256 KB。
• 每 zone 路由 1,000；每 zone 自定义域 100。

超限表现：免费日请求超限返回 Error 1027；CPU/内存超限返回 Error 1102（exceeded resource limits / exceededMemory）。

1.6 定价

• Workers Free：永久免费，含上表免费额。
• **Workers Paid（约 ****$5/月）**：解锁上表 Paid 配额（无限请求、更长 CPU 时间等）。超出 CPU/请求等部分按 Workers 计价规则计费。具体以官方定价页为准。

1.7 最佳实践

• 用 Smart Placement 让计算靠近数据源；把静态资源交给 Cloudflare assets / CDN 层，可不计 Worker 调用。
• 减少子请求次数，善用缓存（Cache API / KV）避免每次请求都回源。
• 控制 CPU 时间：await 的 IO 不计入，但要避免在主线程做重计算。
• 免费层每天 10 万请求，中小站点通常够用；预估流量接近上限时及时升级 Paid。

二、Cloudflare D1 —— Serverless 关系型数据库

2.1 产品定位

D1 是 Cloudflare 的托管式 Serverless 数据库，提供 SQLite 的 SQL 语义，内建灾难恢复，可通过 Worker 或 HTTP API 访问。它的计费只与「查询 + 存储」相关，且无出网流量费。Free 与 Paid 计划均可用。

2.2 核心特性

• SQLite 兼容：沿用熟悉的 SQL 语法与客户端 API，迁移成本低。
• 内置灾难恢复：通过 Time Travel 实现时间点恢复。
• 全球读副本（Global Read Replication）：可添加只读副本，把读查询放到离用户更近的区域，降低延迟、扩展读吞吐。
• 为隔离而生的多库：可以零额外成本创建成千上万个数据库用于隔离（例如多租户场景）。

2.3 关键概念

• 按行计费（Rows read / Rows written）：查询扫描了多少行算多少「行读」，写入/更新/删除了多少行算多少「行写」；行的大小与列数不影响计数。建索引能大幅降低扫描行数。
• Time Travel（时间点恢复）：可把数据库恢复到过去若干天内的任意一分钟。
• Scale-to-zero：不运行查询就不计计算费；只有存储超量才计费。
• 读副本不额外收费：副本产生的仍是按 rows_read / rows_written 的正常计费。

2.4 典型场景

• 需要 SQL 查询能力的内容/关系型数据：文章、用户、评论、配置、索引。
• 实时列表/聚合查询（配合边缘缓存）。
• 多租户隔离（每个租户一个库）。

2.5 配额与限制

其他硬性限制（Free/Paid 相同，除非注明）：

• 每表最大列数：100；单库行数无上限（受单库容量约束）。
• 单行（字符串 / BLOB / 整行）最大 2 MB。
• 单条 SQL 语句长度上限 100 KB；单次查询绑定参数上限 100；单 SQL 函数参数上限 32；LIKE/GLOB 模式上限 50 字节。
• 单次查询时长上限 30 秒。
• 单脚本绑定资源数约 5,000（不含环境变量/密钥）。
• 文件导入（d1 execute）上限 5 GB；Time Travel 恢复操作 10 次 / 10 分钟 / 每库。

2.6 定价

• 免费日限额每日 00:00 UTC 重置；月度包含量按订阅日重置。
• 无数据出网（egress）费。
• 超免费日限额后 D1 会拒绝查询并返回超限错误；存储满需清理后才能继续写入/建表/建索引。

2.7 最佳实践

• 为高频过滤字段建索引，否则全表扫描会让 rows_read 蹭上去。
• 列表/分类/标签这类读多写少的查询交给 D1 实时查询 + 边缘缓存，比维护一堆静态列表更省。
• 注意单库 500 MB（Free）/ 10 GB（Paid）上限，大内容（如整篇 HTML、媒体）应放到 R2 而非 D1。
• 监控 meta 对象返回的 rows_read / rows_written 来估算账单。

三、Cloudflare R2 —— 零出网费的对象存储

3.1 产品定位

R2 是 Cloudflare 的对象存储，与 S3 兼容。它最大的卖点是不收数据出网（egress）带宽费——这正是传统云存储最贵的部分。适合存放大量非结构化数据。

3.2 核心特性

• S3 兼容 API：可复用大量现成的 S3 工具与 SDK。
• 零出网费：从 R2（含 Workers API、S3 API、r2.dev）直接出网到互联网免费。
• 存储类别：Standard（标准）与 Infrequent Access（低频访问，更便宜的存储但取回收费、30 天最低存储时长）。
• Location Hints：建桶时可指定数据主要访问区域。
• 公开访问：支持 r2.dev 托管公开端点与自定义域名公开桶。
• 安全：支持 CORS、桶级作用域令牌（bucket scoped tokens）、Jurisdictions 数据属地。

3.3 关键概念

• Bucket（桶）/ Object（对象）/ Key（键）：R2 以「桶 → 对象（用 key 寻址）」组织数据；对象由数据与元数据组成。
• Class A / Class B 操作：A 类（写入、列举、复制等状态变更）更贵；B 类（读取、HEAD 等）更便宜；删除类操作免费。
• **公开端点 **r2.dev：仅供测试，有可变限流；生产请绑自定义域名。

3.4 典型场景

• 云原生应用存储、Web 内容/媒体托管。
• 播客音频、视频源文件。
• 数据湖（分析 / 大数据）、机器学习产物与数据集。
• 把生成的静态 HTML、图片、风格包资源落地（如 CMS 单页）。

3.5 配额与限制

• Cloudflare REST API 对 R2 限流：1,200 次 / 5 分钟（跨所有 R2 REST 操作）。
• r2.dev 公开端点可变限流（数百请求/秒级），超限临时节流并返回 429。

3.6 定价

• Infrequent Access（低频访问）：存储 $0.01 / GB·月，Class A $9.00 / 百万，Class B $0.90 / 百万，取回收费，30 天最低存储时长。免费额度不适用于该类。
• 免费操作：DeleteObject、DeleteBucket、AbortMultipartUpload 不计费。

3.7 最佳实践

• 大文件 / 媒体 / 静态 HTML 放 R2，比 D1 划算得多。
• 生产环境务必绑自定义域名，别用 r2.dev。
• 单对象上限 5 TiB、单分片 5 GiB；超大文件用多分片上传（最多 10,000 分片）。
• 给同一 key 的高频并发写入要限流到 ≤ 1 次/秒，否则会被 429。

四、Cloudflare KV —— 全球键值存储

4.1 产品定位

Workers KV 是一个全球、低延迟的键值存储，适合高读取量、低延迟的动态 API 与网站。它面向「读多写少」的场景，例如缓存 API 响应、存用户配置/偏好、存鉴权信息。

4.2 核心特性

• 全球低延迟读取：数据分布到全球边缘，靠近用户的节点就近读。
• 简单数据模型：put / get / list / delete 四件套，通过 Bindings 或 REST API 访问。
• Jurisdictions（数据属地）：可把命名空间限制在特定司法辖区以满足合规。
• TTL 过期：键可设过期时间自动删除。

4.3 关键概念：最终一致性

KV 是最终一致的：一次写入会被放入队列，通常在数秒内传播到全球边缘节点（多数情况下更快）。因此刚写入后短时间内，某些区域可能仍读到旧值。它不适合需要强一致、写后立即读的实时数据——这类需求应选 D1 或 Durable Objects。

关键提醒：list** 操作很贵**。任何需要「列举一堆键」的逻辑（如批量缓存、侧边栏、RSS）都应优先用 Cache API 或 D1，而不是堆在 KV。

4.4 典型场景

• 缓存 API 响应、站点配置快照、用户配置/偏好、鉴权细节。
• 跨 isolate 共享的小体积、读多写少的配置。

4.5 配额与限制

其他硬性限制（Free/Paid 相同）：

• 键（key）大小 ≤ 512 字节；键元数据 ≤ 1,024 字节。
• 值（value）大小 ≤ 25 MiB。
• 最小 cacheTtl：30 秒。
• 命名空间内键数：无限。

Workers KV Instant（测试版）：写 1 次/秒、存储 1 MB、键 10,000、键大小 300 字节、不支持元数据、值大小受 1 MB 总容量约束、不支持列表分页。

4.6 定价

• Free 计划含上表免费额度；Paid 计划读取/写入/存储无限（按 KV 计价，以官方定价页为准）。

4.7 最佳实践

• 只放「读多写少」的小配置；别把需要频繁列举的数据放进来。
• 慎用 list，优先 Cache API / D1。
• 注意最终一致性——不要依赖「写入后立即全局读到」。
• 单个值 ≤ 25 MiB；键 ≤ 512 字节。

五、横向对比与选型指南

5.1 四款产品速查表

5.2 什么时候选哪个

• 需要跑逻辑 / 处理请求 → Workers（所有方案的入口）。
• 需要关系查询、事务、实时列表 → D1（强一致、按行计费、读便宜）。
• 需要存大文件、HTML、图片、备份 → R2（无限容量、零出网费）。
• 需要全球低延迟、读多写少的小配置/缓存 → KV（但接受最终一致、慎用 list）。
• 需要强一致的状态协调（如计数器、会话）→ 考虑 Durable Objects（本文未展开）。

5.3 组合案例：yuebin.uk 怎么用

yuebin.uk（CF Static Export Pro）是这套组合的典型用法——动静分离：

• Workers 当 CMS 运行载体（路由、渲染、注入评论）；
• R2 存文章单页 HTML、媒体、风格包（便宜、无限容量、读不按行计费）；
• D1 存文章、分类、评论、用户、设置、索引（SQL 实时列表的来源）；
• KV 只存 site:ctx 一个站点配置快照（读多写少、跨 isolate 配置缓存）。

列表缓存、RSS、侧边栏这类「要列举」的需求被刻意搬到 Cache API，KV 仅保留一个键——正是 5.2/4.3 选型原则的实践体现。

附：数据来源与说明

• 官方文档仓库：cloudflare-docs@production → src/content/docs，涵盖 workers、d1、r2、kv 的 Overview / Limits / Pricing 文档。
• 文中所有配额、限制、价格均整理自上述官方文档（截至 2026-10）。Cloudflare 可能随时调整限额与定价，正式决策前请以 developers.cloudflare.com 最新页面为准。
• 本文为中文重组与系统梳理，并非官方译文；技术术语保留英文原词（如 isolate、binding、Class A/B 操作）以便对照官方资料。