过于信任AI，导致 cloudflare d1 超刷982亿行引发超额账单
起因：把监控丢给 AI 后，我被 D1 的读取量上了一课
上个月 GPT 5.6 发布，我手痒开启了 /goal 模式。
我的架构中有一些边缘业务运行在 Cloudflare Workers + D1 上。当时我想给系统补一套指标监控，便随口向 AI 下达了任务：“帮我做一套边缘业务的状态监控”。
AI 开启了自主规划与执行：它不仅完成了指标采集代码，还自作主张写了一个每 30 秒执行一次的 Edge D1 定时监控查询。更致命的是，为了统计待处理的目标状态，它的 SQL 逻辑里包含了缺乏有效索引的反复关联扫描与全表比对。
对于 AI 来说：有数据、逻辑闭环、单元测试全绿，任务就算完美交付。但它完全不知道 D1 是按底层扫描行数计费的。
几天后我查看账单监控，直接傻眼——D1 的读取量呈现灾难性暴增，光是事故爆发的两天，就刷出了 75.095B（约 751 亿行） 的读取量，整个账期累计达 98.27B（982.7 亿行）。
Cloudflare UTC 监控面板数据：
- 7 月 27 日：D1 总读取 43.389B，该监控 SQL 贡献 41.500B（占比 95.6%）。
- 7 月 28 日：D1 总读取 34.226B，该监控 SQL 贡献 33.595B（占比 98.2%）。
- 两天合计：监控 SQL 累计扫描 75.095B 行，占这两天总用量的 96.75%。
定价拆解：为什么一行简单的 SQL 能产生 73 刀额外账单？
1. Cloudflare D1 计费逻辑
Cloudflare D1 的核心计费指标是 Rows Read（扫描行数） 与 Rows Written（写入行数），并非按照返回给客户端的数据量计费。
| 项目 | Workers Free | Workers Paid ($5/月) |
|---|---|---|
| Rows Read | 500 万 / 天 | 250 亿 / 月（包含） |
| 超额 Rows Read | — | $0.001 / 百万行 |
| Rows Written | 10 万 / 天 | 5000 万 / 月（包含） |
| 超额 Rows Written | — | $1.00 / 百万行 |
| 存储空间 | 5 GB | 5 GB（包含），超额 $0.75 / GB·月 |
| 出站流量 | 免费 | 免费 |
关键陷阱：D1 的 Rows Read 计算的是数据库底层引擎实际遍历扫描的行数。
哪怕你的SELECT最终只返回 10 条数据，但由于缺乏索引或低效 JOIN 导致 SQLite 引擎扫了全表 100 万行，计费时就会严格按 100 万 Rows Read 结算。
2. Workers 与 D1 的叠加链路
Workers Paid 基础套餐包含每月 1000 万次请求和 3000 万 CPU ms。每 30 秒跑一次 Cron Worker 本身几乎不消耗什么资源，但其背后的调用放大效应十分惊人：
$$\text{Cron Worker (每 30 秒)} \xrightarrow{\text{触发}} \text{无索引全表关联 SQL} \xrightarrow{\text{单次扫描数千万行}} \text{巨量 Rows Read}$$
3. 最终账单算式
- 账期总读取：
98.27B Rows - Paid 计划免费额度：
25.00B Rows - 超额读取量：
98.27B - 25.00B = 73.27B Rows - 超额扣费： $$\frac{73.27 \times 10^9}{10^6} \times $0.001 = $73.27$$
虽然 73 刀没有造成毁灭性损失，但这完全是因为 D1 的单价极低（10 亿行才 1 美元）。如果换成按写入计费的数据库或按 token 计费的 API，这类无界死循环足够让人直接破产。
止损与申诉：如何向 Cloudflare 申请减免？
定位问题后，我第一时间下线了对应的采集 Worker。既然故障已经发生，抱着试试看的心态，我开始调研 Cloudflare 是否支持非恶意故障的一次性账单减免（Courtesy Credit）。
通过检索，我发现遇到类似情况的开发者不在少数：
几个经典的减免参考案例：
- My $5/month Cloudflare bill hit $4,868 because of an infinite loop（全额减免约 $4500+）
- D1 one-time overage ~$564 — fixed, requesting credit before invoice
- 官方社区工单记录 #01953111 与 #02179960
提交工单模板（8 月 2 日）
向官方沟通时，要做到数据清晰、态度诚恳、说明根因并证明已经彻底修复：
Hello Cloudflare Billing Support,
I am writing to respectfully request a one-time courtesy credit or waiver for an accidental D1 Rows Read overage of approximately USD 73.27.
Account ID: xxxxD1 database: xxxxDatabase ID: xxxxxx
Billing details:- Total Rows Read: 98.27 billion- Included Rows Read: 25 billion- Overage: 73.27 billion- Estimated overage charge: ~USD 73.27
This overage was caused by a runaway internal monitoring SQL query, not by production traffic or end-user activity. It was an isolated operational mistake on our side.
Breakdown of the incident days:- July 27, 2026: 43.389B total rows read, of which 41.500B came from the monitoring query- July 28, 2026: 34.226B total rows read, of which 33.595B came from the monitoring query
The monitoring query alone accounted for 75.095B rows over these two days.Excluding this isolated incident, our total usage for the period would have been only approximately 23.175B rows — well below the included 25B allowance.
We identified the issue and permanently disabled the D1 metrics collector on August 2, 2026 at 14:56:09 UTC. We have verified that the query is no longer being issued. The root cause has been fully removed and the problem has already been fixed.
We fully understand how D1 Rows Read billing works and take complete responsibility for this operational error. Additional safeguards have also been put in place to prevent similar issues in the future.
Given that this was a one-time isolated mistake, the issue has already been permanently fixed, and our normal usage remains within the included allocation, we sincerely and respectfully request a one-time courtesy credit or waiver for the 73.27B Rows Read overage.
All relevant evidence (billing details, query analytics, and remediation records) has been attached.
Thank you very much for your time and consideration.
Best regards官方反馈与前置条件（8 月 22 日）
8 月 22 日，Cloudflare 支持团队回复表示可以进入账户信用审核流程，但要求账户必须开启 Billable Usage 监控并配置 Budget Alert（预算告警）。
按要求在 Dashboard 开启 Budget Alert：
随后回复确认：
Thank you very much for your assistance.
I’ve now configured the billable-usage budget alert on my account as requested, with a threshold greater than $10.
Please proceed with the account-level review of the D1 usage and the $73.27 overage from the July 27–28 usage spike.
I really appreciate your help with investigating this issue. I’ll wait for your follow-up regarding the review and any possible one-time credit.
Thanks again for your support!
Best regards最终结果（8 月 25 日）
审核顺利通过。由于当期账单已自动扣款，Cloudflare 将 $73.27 全额退还到了账户余额中（Credit Balance），可直接用于抵扣后续订阅费用。
Vibe Coding 时代的冷思考：当自主 Agent 遇上按量计费
GPT 5.6 的 /goal 模式和传统的 Copilot 辅助补全有本质区别。它更像一个自主 Agent：给它一个目标，它会自主拆解、编写代码、跑测试、修复报错，直到它认为目标达成。
但这里存在一个致命的认知代沟：
- AI 只对逻辑正确性负责，不对你的钱包负责：在 AI 眼中，跑通功能的权重大于一切。它不会考虑“单次查询扫描成本”、“Serverless 冷启动代价”或“第三方 API Rate Limit”。
- 云原生的自我修复（Self-Healing）容易变成刷量放大器：如果代码存在死循环或资源泄漏，现代云平台的容器重启、重试机制会默默掩盖故障，让费用在后台无限累积。Reddit 上就有开发者分享过 AI Agent 死循环生成图片导致 700 刀蒸发 的真实惨剧。
生产环境防背刺指南（SaaS 避坑清单）
在将任务放权给自主编码 Agent 之前，必须在基础设施层建立防御：
- 硬顶预算限制（Hard Limit）高于一切：
- 接入任何 Serverless/SaaS 服务前，第一步不是写代码，而是去 Billing 页面开启 Budget Alert 与 Hard Limit（超额自动熔断）。
- 审计 AI 生成的高频定时任务与 SQL：
- 对任何
setInterval、Cron Trigger或后台 Worker 保持高度警惕。 - 在 D1/SQLite 中，涉及关联查询必须执行
EXPLAIN QUERY PLAN确认命中索引，严禁让无索引扫描暴露在定时轮询中。
- 在应用层设计熔断机制（Circuit Breaker）：
- 限制 Worker 单次执行的超时时间与单批次处理上限（Batch Size）。
- 增加死信队列与异常重试熔断，避免任务失败后无限死循环拉起。
- 小步迭代，禁止无人值守全量发布：
- AI 写完代码后，先在 Local/Staging 观察 Metrics 指标，确认资源消耗符合预期再切流量。
总结：Vibe Coding 确实解放了生产力，但在涉及按量计费（Pay-as-you-go）的基础设施时，千万不要当甩手掌柜。