Cloudflare 免费额度榨干指南：Workers、D1、KV、R2 的边界与活法

独立开发者一年复盘里我写过「月度账单 0 元」。很多人问怎么做到的——答案不是省，是掐着免费额度的线做架构设计。这篇把 Cloudflare 免费档的边界逐项拆开，讲讲我们的用量模型，以及第一个会炸的地方到底在哪。

免费额度总表

数字以官方文档与 Dashboard 实时显示为准，免费档策略会变，但用法不会变：读走缓存、写走批处理、大文件走对象存储。先读额度表再画架构图，顺序反了等于裸奔。

Workers 请求数：最舒服的一项

10 万请求/天对个人项目是天文数字——摊到每小时只有 4,166 次。渡劫code 全部 API、博客评论系统、三端静态站的动态部分都走 Worker，内测期日请求量离上限差两个数量级。

真正的风险不是总量，是单次 10ms CPU：LLM 流式响应的拼装、大 JSON 序列化、没走索引的 join 都可能超。我们的对策是流式响应不缓冲、重活扔给异步上下文——在 Workers 里，CPU 时间才是隐形货币，请求数只是明码标价的那个。

KV：读写不对称，写才是天花板

KV 的免费档极度不对称：读 10 万/天，写只有 1,000/天。我们的 KV 用法有三处：登录写 session、每次 API 请求写限流桶（ratelimit:api:{userId}:{minuteBucket}）、登出删 session。

问题就在第二处：限流桶意味着每一次 API 调用都伴随一次 KV 写。1,000 次写/天，相当于 API 请求持续上限约每 86 秒一次——个人项目随便用，但这是全站第一个会触顶的额度，比 Workers 请求数早得多撞墙。

预案有两种：限流计数降级为 isolate 本地内存（牺牲跨实例精度换零成本，适合个人站的量级），或在 KV 写失败时直接放行（限流降级为尽力而为）。限流组件自己成为单点，是架构里最尴尬的死法——所以这项用量我们列进了重点监控，撞墙之前就该看到曲线抬头。

D1：为「读多写少」而生

评论系统的数据模型完美命中 D1 甜蜜点：5 GiB 存储对文本评论是另一个天文数字；500 万行读/天覆盖任意量级的页面浏览；10 万行写/天——按评论接口 2 条/分钟/指纹的限流算，要把写额度烧满需要连续 69 天不间断被人发评论，真到那天高兴还来不及。

D1 的优化纪律（batch 即事务、keyset 分页、索引先行）在 D1 实战里写过，这里只补一句成本视角：行读按行计费，深分页是烧额度最快的写法——OFFSET 翻一页就多读一段废行。优化手段和免费额度同向，这种巧合是选型选对了的信号。

R2：出流量免费改变一切

R2 最被低估的一条是出流量（egress）永久免费。S3 系存储的账单大头从来不是存储，是流量。个人项目把用户上传、头像、工作区文件放 R2，等于把最不可控的成本项直接归零。10 GiB 存储对代码工作区文件是起步容量，Class A/B 操作限额（100 万/1,000 万次每月）对 CRUD 型用法几乎无感。

渡劫code 的工作区文件就走 R2: ws/{workspaceId}/{path}，元数据进 D1，KV 只放索引——分层的目的就是让每一级存储都待在自己的免费档里，谁也不越界。

Pages：被低估的免费之王

Cloudflare Pages 免费档不限带宽、不限请求数，还白送每个分支的预览部署。博客三端里最烧流量的静态站全放 Pages，动态 API 全走 Workers——把「不限量」的产品用在最可能爆的流量形态上，这是整套 0 元架构的核心思路。Durable Objects 同理：TerminalRoom 长连接是唯一有状态ful 需求的场景，恰好也是 DO 的免费额度最难触达的场景（个人项目的并发终端房间数个十数）。

榨干的本质是分层

最后一条可执行建议：把 Dashboard 的用量页面当日报看。免费额度不是保证书，是悬崖边的护栏——知道每项用了百分之几，才知道哪条增长曲线会先撞墙。额度用超之前 Cloudflare 会发邮件，但读懂用量曲线，比等邮件主动得多。