成本控制与额度监控：免费额度什么时候会用完
免费额度不是一个数字，是五六个数字。它们消耗速度差三个数量级，撞墙的先后顺序也完全不同。这篇做三件事：把每个额度换算成"每小时可用多少"，标出最先耗尽的那个；给出三种监控手段，从看仪表盘到自己记数；最后说清楚什么时候该掏 $5，以及不掏钱时怎么降级。
各额度的原始数字见 56-free-tier-limits-cheatsheet.md，这篇讲怎么盯住它们。超限后的具体报错见 104-troubleshooting-playbook.md。
1. 额度换算
日额度除 24 得到的每小时速率，比原始数字直观得多。
| 项目 | 免费额度 | 折算速率 | 谁先撞 |
|---|---|---|---|
| Workers 请求 | 100,000/天 | 4,166/小时 | 中等 |
| Workers CPU | 10 ms/次 | — | 复杂逻辑才撞 |
| KV 读 | 100,000/天 | 4,166/小时 | 中等 |
| KV 写 | 1,000/天 | 41/小时 | 最先 |
| 子请求 | 50/请求 | — | 扇出型接口 |
| R2 存储 | 10 GB-月 | — | 图多的站 |
| R2 Class A | 100 万/月 | 约 33,000/天 | 很少 |
| R2 Class B | 1000 万/月 | 约 333,000/天 | 很少 |
| Pages 构建 | 500/月 | 约 16/天 | 自动提交的项目 |
每小时 41 次 KV 写，意味着任何"每次请求都写一次"的设计都会在几分钟内把一天的量烧完。限流计数、点击统计、访问日志、在线人数，这几个常见需求全都是每请求一写，全都会撞在这一项上。
2. 五个隐性消耗
静态页放 Pages，请求不算 Workers 额度。但如果这个页面是 Worker 返回的 HTML，每次访问都是一次 Worker 请求，外加可能的 KV 读。同一个站点换个承载方式，额度消耗差一个数量级。
/favicon.ico 与 404 页面也走 Worker。一个没有资源处理的站点，每次页面加载可能产生 3 到 5 个请求（页面、favicon、几个静态资源），浏览器重试和爬虫会把数字再抬高。
定时任务按次计。每分钟一次的探测，一天 1440 次，看起来只占 1.4%，但同时它还会产生对上游的 fetch（子请求）和对 KV 的读。
构建次数被自动提交烧掉。仓库里有定时抓取生成日报、或 CI 每次跑完回写文件的流程，一天几十次构建，半个月就用完 500 次。
同一个 KV key 的写入被限到每秒一次。把热点配置项放在一个 key 里高频更新，会看到写入被丢弃，而额度可能还没用完。
3. 三种监控手段
控制台仪表盘最直接：Workers & Pages 的 Overview 有请求数与错误率，KV 页面有读写曲线，R2 有存储与操作数。缺点是只有聚合值，且要人去看。
GraphQL Analytics API 能把数据拉出来自己画图或报警：
curl -s https://api.cloudflare.com/client/v4/graphql \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"query":"{ viewer { accounts(filter:{accountTag:\"$ACCOUNT_ID\"}) { workersInvocationsAdaptive(filter:{date_geq:\"2026-11-01\"},limit:100) { sum { requests errors } dimensions { datetime } } } } }"}'Token 需要带 Analytics 读权限。拿到的数据可以推进自己的看板，也可以写个定时任务，超过阈值就发消息。
自己记数最可靠：在请求入口加一次计数写入，按小时聚合后存 KV（每小时只写一次，不撞额度）。代价是多一次读写，而且计数本身也消耗额度——适合给关键接口做，不适合全站铺开。
4. 阈值与降级
| 用量 | 动作 |
|---|---|
| 50% | 什么都不做，记一笔 |
| 70% | 检查是否有异常流量（爬虫、被刷、循环调用） |
| 85% | 关闭非核心功能：统计、推荐、图片变换 |
| 95% | 核心接口降级为缓存响应，写接口返回 503 并给出说明 |
Workers 路由的 fail open / fail closed 也是降级开关。纯展示站设 fail open，额度耗尽时直接由边缘返回静态资源，用户看到的还是页面；带鉴权的接口设 fail closed，宁可 1027 也不能让请求绕过检查。
5. 什么时候该付 $5
Workers Paid 是 $5/月起，含每月 1000 万请求与 3000 万 CPU 毫秒，超出后每百万请求 $0.30、每百万 CPU 毫秒 $0.02。这个价格的门槛很低，判断标准不是"够不够用"，是"故障的代价"。
如果额度耗尽会让业务停摆、或者要花时间做复杂的省额度改造，$5 比改造便宜。反过来，个人站、示例项目、内部工具，免费档加上降级策略就够。付费之后仍然要看额度，1000 万请求听起来很多，被爬虫刷起来也是几天的事。
6. 常见问题
额度什么时候重置？按 UTC 零点，对国内是早上 8 点。压测和排障时注意这个时间点，别把"早上 8 点后突然恢复"当成故障自愈。
超了会被扣钱吗？免费档不会扣钱，会停止服务并返回 Error 1027。付费档按量计费，没有硬上限，所以付费之后监控反而更重要。
能不能给额度设硬上限？可以在账号级别设支出上限（Spend limit），达到后相关服务停止。这个开关值得在开通付费的第一天就设上。
小结
免费额度里最先耗尽的几乎总是 KV 写入（41 次/小时），其次是 Workers 请求与 KV 读（各 4,166 次/小时）。设计的顺序应该是：先确认没有"每请求一写"，再看请求量，最后才考虑 CPU 时间。
监控的投入要跟业务重要性匹配。个人站看一眼仪表盘就够，有真实用户的接口至少要有阈值告警与降级开关。成本优化的具体动作在 105-performance-cost-checklist.md 里按收益排了序。
数据来源与检索时间
检索时间 2026-11-10。
| 来源 | URL | 对应数据 |
|---|---|---|
| Workers 定价 | https://developers.cloudflare.com/workers/platform/pricing/ | 免费 100,000/天、10 ms CPU；付费 $5/月起、1000 万请求、3000 万 CPU 毫秒、$0.30/百万、$0.02/百万 |
| KV 限额 | https://developers.cloudflare.com/kv/platform/limits/ | 100,000 读/天、1,000 写/天、同 key 1 次/秒、1 GB 存储 |
| R2 定价 | https://developers.cloudflare.com/r2/pricing/ | 免费 10 GB-月、100 万 Class A、1000 万 Class B |
| Pages 限额 | https://developers.cloudflare.com/pages/platform/limits/ | 500 构建/月 |
核验说明
- 文档核对：Workers 与 R2 的免费/付费数字来自 2026-11-10 抓取的定价页，KV 与 Pages 数字来自限额页。
- 未做：没有把任一额度跑到上限；没有实际调用 GraphQL Analytics（示例中的
$CF_API_TOKEN、$ACCOUNT_ID为占位符，查询语句按公开 schema 写，未验证返回结构）；支出上限开关未在账号内设置。 - 折算速率与用量阈值为按额度的算术推导，是建议值而非官方规定。