1.4 成本心得：免费额度怎么用、账单怎么失控、怎么设预算防线

免费额度：不是不用，是分层用

Spark 免费计划的正确打开方式，不是“抠着用”，而是“分层用”。我的原则很简单：开发与测试放 Spark，生产再上 Blaze。

具体一点，我的一般做法是：

• 开发期所有调试都在 Spark 项目里进行，配着 Emulator Suite 用，连线上配额都不消耗。
• 测试数据和真实数据分项目，测试项目永远留在 Spark 上。
• 只有当项目确定要见真实用户了，才把生产项目升 Blaze。

这样分层的好处是：即使账单出了幺蛾子，爆炸半径也被限制在生产项目里，而且你对生产项目的每一分钱去向心里有数。

一个反直觉的心得：免费额度最有价值的部分不是省下的钱，而是它给你的反馈信号。Spark 配额是天花板，你的用量什么时候逼近天花板，说明你的数据模型该优化了，或者项目该挪窝了。把它当成一个免费的用量仪表盘来读，比只当省钱工具值钱。

至于各产品的具体免费额度数字，我不在书里写死——官方定价页永远比我这本书新鲜，以它为准。

账单失控的四种经典姿势

在 Blaze 上，账单失控不是意外，是有固定剧本的。我见过的翻车，翻来覆去就这几类：

挨个说说我看到的翻车细节。

无限流监听是最常见的一种。Firestore 的实时监听按读取计费，一个监听挂在整个大集合上，就等于每来一个新文档都读一次、用户每刷新一次页面都重新全量读一遍。用户少的时候没感觉，等量一上来，读取量的增长是用户数乘以监听数乘以文档数，乘法里每一项都在涨，账单自然起飞。修法是监听永远带查询条件：限定文档数量、限定时间范围，能分页就不全量。

循环重试的云函数是隐蔽的一种。云函数处理失败后如果无脑重试，而失败的原因又触发另一个函数……失败在函数之间传染，每次重试都是计费的调用。防线是给重试设明确上限、加退避间隔，更关键的是把可能互相触发的函数梳理清楚，别让错误雪崩。

测试环境没关属于低级但高发。测试用的云函数定时任务忘了删、测试库开了按量计费、跑着实验的容器没停——这些消耗不猛烈，但它是持续性的，一个月下来在账单里是一笔说不清的固定支出。所以测试环境的纪律是：要么不碰 Blaze，要么用完即删。

公开写接口被灌垃圾数据最冤枉。安全规则配置成任何人可写，等于把数据库的写入口开在了大街上，爬虫和恶意脚本灌进来的垃圾数据，每一笔写、每一笔存都在烧你的钱。这类事故还有一个隐形代价：垃圾数据清理本身也是操作量，也计费。

预算防线四件套

上 Blaze 之前，把下面四样配齐。这是我的固定检查清单：

• 预算告警：在绑卡的账号体系里设预算，到了阈值收邮件提醒。这是所有防线里最基本的一条，相当于给钱包装了个烟雾报警器。第一笔 Blaze 账单来之前就必须配好，不是出了事再配。
• 配额上限：在具体产品层面设用量上限，比如把某项资源按天的最大用量卡死。它和预算告警的区别是：告警是通知你，上限是直接把水龙头拧住。两者要配合用。
• App Check 防滥用：校验请求确实来自你自己的应用，挡掉脚本和爬虫的直连灌垃圾。上面第四种失控姿势的专门解药。
• 密钥不进前端：凡是能直接花钱的能力（出站网络、调用计费接口），凭证只放在云函数等服务端环境里，前端永远不碰。前端代码是公开的，写在前端就等于写在公告栏上。

这四件套的思路可以概括成一句话：告警让你知道，配额让它停，校验挡住坏人，密钥管住自己。

心得：成本意识要长在数据模型上

最后说一个更深层的体会。很多人把成本控制理解为“事后看账单”，但托管平台的钱是在数据模型设计那一刻就决定了大半的。同样一个功能，监听设计成全量还是限量、读一次还是读十次，账单可能差出一个量级。

所以我的习惯是做任何功能之前多问一句：这个功能上线后，每天会产生多少读、多少写、多少存储？这三个数字估出来，成本模型就有了。估算不需要精确到个位数，只需要知道量级——量级错了，才是真正的灾难。

一句话收尾这一篇：Firebase 的成本不是管理出来的，是设计出来的。防线四件套是保险，数据模型才是根本。