Firebase 免费额度够用吗，超出后多少钱
「Firebase 免费额度够用吗，超出后多少钱」
Firebase 的 Spark 计划（免费档）在 Google 产品里算是个异类。它不像 GCP 那样新用户送 300 美元试用金、到期就停，而是真正意义上的"永久免费"——只要你不触发某些隐藏开关，项目可以一直跑下去。但这个"一直"有多少水分，超出后的账单能吓人到什么程度，很多开发者是在生产环境踩了坑才真正弄明白。
Spark 计划的边界：不是无限，而是"够用就好"
Spark 计划的核心逻辑是配额制，按月重置。最常见的几个产品里，Authentication 每天允许 50,000 次匿名登录或邮箱验证，Cloud Firestore 每天 50,000 次读取、20,000 次写入、20,000 次删除，Cloud Functions 每月 200 万次调用、400,000 GB-秒、200,000 CPU-秒，Cloud Storage 每天 1 GB 出站流量。这些数字看起来对小型应用很友好，但"小型"的定义在不同场景下差异巨大。
Firestore 的计费模型有个反直觉的地方：它按文档读取次数收费，而不是按数据量。你查一个集合，返回 1000 条文档，就是 1000 次读取。如果客户端代码写得不讲究，在 RecyclerView 里每次滑动都触发全量查询，或者用了没有 pagination 的实时监听器，额度消耗速度会远超预期。更隐蔽的是，Firestore 的离线持久化默认开启，本地缓存命中时不会计费，但一旦缓存失效或用户首次安装，冷启动的读放量可能直接把你的日配额吃掉大半。
Cloud Functions 的免费额度在 2023 年有过一次调整，Google 把内存分配和 CPU 时间的计算方式从"固定 256MB"改成了按实际配置比例。这意味着如果你为了性能把函数内存调到 1GB，同样的调用次数下，GB-秒消耗会线性增长。很多老项目迁移后才发现，原本"够用"的 200 万次调用，现在因为内存配大了，实际能支撑的调用量只有原来的四分之一。
Blaze 计划的真相：不是"按需付费"，是"按量计费且可能失控"
Spark 用完后，Firebase 会提示你升级到 Blaze 计划（按量付费）。这个升级不是可选的——一旦某项服务超出配额，相关功能就会停止工作，除非你绑定信用卡开启 Blaze。Blaze 的定价结构在官方文档里分散在各个产品页面，需要手动汇总。
Firestore 在 Blaze 下是 $0.06/100,000 次读取、$0.18/100,000 次写入、$0.02/100,000 次删除。存储和带宽另算。Cloud Functions 是 $0.40/百万次调用，加上 $0.0000025/GB-秒 和 $0.0000100/CPU-秒。Cloud Storage 出站流量 $0.12/GB（美国区域）。Authentication 在 Spark 的 50,000 日活后，超出部分 $0.01/验证。
这些单价单独看都不贵，但组合起来很容易产生账单惊吓。一个典型场景：你的应用上了某个国家的应用商店推荐，日活从 5,000 涨到 50,000。Firestore 的读取从每天 20 万次涨到 200 万次，超出 Spark 的 50,000 限制后，Blaze 计费直接按 $0.06/100,000 算，每天多出来的 150 万次读取就是 $0.90。一个月下来 $27，似乎还能接受。但如果你的数据模型设计得不好，某个页面每次打开都读取 50 个文档，50,000 日活 × 50 文档 × 每天打开 3 次 = 750 万次读取，超出部分 745 万次，每天 $4.47，一个月 $134。这还只是 Firestore 一项。
更危险的是 Cloud Functions。2022 年有开发者在一个 GitHub issue 里分享了他的账单：一个处理图片缩略图的函数，因为上游传入了一个异常大的文件，函数超时重试，CPU 时间累积到 30,000 秒，单月账单 $780。Firebase 的函数超时上限默认是 60 秒，可以配置到 9 分钟，但超时不会自动终止计费——它会重试。如果你没设置 maxInstances 限制，并发突增时实例数会无限扩张，费用跟着线性增长。
那些文档里没写清楚的"免费"陷阱
Firebase 的免费额度有几个灰色地带，官方文档不会主动强调。
Realtime Database 和 Firestore 是两套产品，Spark 计划的额度不互通。很多老项目从 Realtime Database 迁移到 Firestore 时，误以为"数据库免费额度"是共享的，结果两个库同时跑，Realtime Database 的 100 并发连接和 10 GB 下载量很快耗尽，而 Firestore 的额度还没动。更麻烦的是，Realtime Database 的 Blaze 定价是 $5/GB 下载量，比 Firestore 的存储计费贵一个数量级，如果你的应用还有遗留代码在读取 Realtime Database，这部分费用很容易被忽略。
Cloud Messaging（FCM）在 2024 年有过一次重大变更。之前 FCM 的"数据消息"和"通知消息"都不收费，但 2024 年 7 月开始，针对非 Google 移动服务（也就是非 GMS）设备的推送，比如国内某些厂商的 Android 定制系统，或者你主动选择通过 FCM HTTP v1 API 发送的某些高级功能，开始计入 Cloud Messaging 的付费层级。虽然 Spark 计划仍然有每月 1 亿条消息的免费额度，但"非 GMS 设备"的定义和计费触发条件在文档里写得非常模糊，有开发者反馈同样的代码在小米手机上产生了计费，在 Pixel 上没有。
另一个坑是 Firebase Extensions。官方扩展市场有很多预置的 Cloud Functions，比如"Resize Images"或"Translate Text"。这些扩展安装时会自动创建 Cloud Functions 和可能的其他资源（如 Cloud Storage 触发器）。Spark 计划下，扩展占用的函数额度会计入你的 200 万次/月限制。但扩展的默认配置往往比较保守，比如图片缩放扩展默认使用 1GB 内存，这会让你的 GB-秒消耗比自建函数高很多。更隐蔽的是，某些扩展会创建 Cloud Scheduler 作业，而 Scheduler 在 Spark 计划下没有免费额度，直接按 $0.10/作业/月收费——虽然钱不多，但它是 Spark 计划里少数"没有免费层"的服务，很多开发者第一次绑卡就是为了付这 $0.10。
成本控制：一些实际有效的策略
在 Blaze 计划下，Firebase 提供了几种内置的成本控制手段，但都需要主动配置。
Firestore 可以设置每日支出预算，在 Google Cloud Console 的"配额"页面里。注意这个预算不是硬上限——它达到阈值后会发邮件告警，但不会停止服务。真正的硬限制需要你在 Cloud Billing 里设置预算告警并关联 Cloud Function 去主动禁用 API，这整套流程对独立开发者来说门槛不低。一个更务实的做法是在应用层做缓存激进策略：用 Room 或 DataStore 做本地缓存，Firestore 查询时优先走缓存，只有明确需要新鲜数据时才强制服务端读取。Firestore 的 Source.CACHE 和 Source.SERVER 参数可以精确控制这个行为，但官方教程里很少强调。
Cloud Functions 的成本控制更关键。务必设置 maxInstances，建议根据你的日活峰值倒推。一个经验值：如果平均响应时间是 200ms，日活 10,000，峰值大概是平均的 3-5 倍，那么 maxInstances 设到 50 通常够用。如果你处理的是异步任务（比如图片处理、数据清洗），考虑用 Cloud Tasks 或 Cloud Scheduler 把突发流量削峰填谷，而不是直接暴露 HTTP 函数。Cloud Functions 的冷启动时间虽然比 AWS Lambda 好一些，但内存配到 1GB 时，冷启动的计费成本也更高——对于非 latency-sensitive 的任务，256MB 或 512MB 往往更划算。
Cloud Storage 的出站流量是另一个大头。Firebase Hosting 和 Cloud Storage 的 CDN 是分开的。如果你把用户上传的图片直接存在 Cloud Storage 然后让客户端走 gs:// URL 下载，出站流量按 $0.12/GB 计费。但如果你通过 Firebase Hosting 做反向代理，或者把静态资源放到 Hosting 上，Hosting 的 CDN 流量在 Spark 计划下每天 10GB 免费，Blaze 计划下 $0.15/GB——看起来比 Storage 贵，但 Hosting 的缓存命中率通常更高，实际支出可能更低。更常见的优化是启用 Cloud Storage 的 CDN 缓存，这需要手动在 Cloud Console 里配置，Firebase 控制台里找不到入口。
和其他平台的横向对比：不是谁更便宜，而是计费模型是否匹配你的架构
很多开发者会在 Firebase 和 Supabase、AWS Amplify、MongoDB Realm 之间犹豫。直接比单价意义不大，因为计费维度完全不同。
Supabase 的免费层（免费计划）提供 500MB 数据库、2GB 存储、无限 API 调用，但数据库是 Postgres，查询优化得当的话，同样的功能可能比 Firestore 的文档读取次数少一个数量级。代价是 Supabase 的实时功能（Postgres 的 LISTEN/NOTIFY）在高并发下需要连接池管理，而 Firestore 的实时监听器是无状态的，扩展性更好但计费更细。如果你的应用是"大量小查询"模式，Firestore 的按文档计费会吃亏；如果是"少量复杂查询"，Supabase 的 Postgres 可能更省。
AWS Amplify 的 DataStore 在本地缓存策略上比 Firebase 更激进，默认是离线优先的，同步到 DynamoDB 的后台策略可以配置。但 Amplify 的免费层是 AWS 新用户 12 个月免费，不是永久免费，到期后 DynamoDB 的按读写容量单位计费（RCU/WCU）需要预置或按 on-demand，学习曲线比 Firestore 的"自动扩缩容"陡很多。Firebase 的优势在于"默认配置就能跑"，而 AWS 几乎每一步都需要你做容量规划。
MongoDB Realm 的同步模式是"全文档同步"，也就是客户端有一个完整的本地 MongoDB 副本，后台增量同步。这对离线体验极好，但初始同步的文档传输量可能很大。Realm 的免费层是 25 个并发同步用户，超出后按 $0.08/百万次同步请求计费。如果你的用户每天打开应用 10 次，每次同步算一次请求，25 个免费用户其实只够很小的团队内部工具。
我个人觉得，Firebase 的计费模型最适合"读多写少、文档结构扁平、实时需求适中"的应用。如果你的数据关系复杂、需要大量聚合查询，或者用户行为是"打开一次读几百条文档"，Firestore 的计费会惩罚这种访问模式。
一个具体的成本估算案例
假设你在做一个类似"极简日记"的 Android 应用，功能很简单：用户每天写几条文字日记，支持图片上传，首页是时间线倒序排列，支持按日期搜索。
日活 5,000，平均每个用户每天打开 2 次，每次首页加载读取最近 30 条日记。Firestore 读取：5,000 × 2 × 30 = 300,000/天，超出 Spark 的 50,000，每天超 250,000，$0.15/天，$4.50/月。写入：5,000 用户 × 平均 0.5 条/天 = 2,500 次，在 Spark 的 20,000/天内，免费。图片存储：假设平均 2MB/张，0.5 条/天 × 30 天 × 2MB = 30MB/月/用户，但存储计费是累加的，5,000 用户一年下来 1.8TB，Cloud Storage 存储费 $0.026/GB/月，约 $47/月。图片下载流量：每次打开加载 5 张缩略图，100KB/张，5,000 × 2 × 5 × 100KB = 5GB/天，超出 Spark 的 1GB/天，每天 4GB，$0.48/天，$14.40/月。Cloud Functions 处理图片上传时生成缩略图：5,000 × 0.5 = 2,500 次/天，75,000/月，在 200 万次免费额度内，但内存配 512MB 的话，每次处理 2 秒，75,000 × 2s × 0.5GB = 75,000 GB-秒，超出 400,000 GB-秒 免费额度？不，75,000 在 400,000 内，免费。
这个案例的总成本：Firestore 读取 $4.50 + Storage 存储 $47 + Storage 出站 $14.40 = $65.90/月。如果你没做缩略图，原图直出，Storage 出站可能翻 10 倍。如果你在首页用了 Firestore 的实时监听器而不是单次查询，每次用户滑动都可能触发重新监听，读取次数再翻几倍。
这个估算里没有算 Authentication（免费）、Analytics（免费）、Crashlytics（免费）。Firebase 的免费策略明显偏向"吸引你进来，在数据存储和传输上收费"，这和 GCP 的整体逻辑一致。
绑定信用卡前应该检查的几件事
很多开发者升级到 Blaze 是因为某项服务突然超限，情急之下绑卡。但绑卡后，Firebase 的计费是关联到整个 Google Cloud 项目的，意味着同一个账单账户下的其他 GCP 服务（比如你为了调试开的 Compute Engine 实例）也会开始计费。
建议绑卡前做这几步：在 Cloud Console 的 Billing 页面设置预算告警，建议设成你预期月费的 50%、100%、150% 三档；在 Firebase 控制台逐个检查每个产品的用量趋势，至少看过去 3 个月；确认 Cloud Functions 的 maxInstances 和 timeout 都已配置；检查是否有未使用的 Firebase Extensions 或测试环境项目仍在消耗额度。
还有一个冷门知识点：Firebase 的 Spark 计划项目可以导出数据后删除，但 Blaze 计划项目如果欠费，Google 会保留项目一段时间然后删除，期间产生的存储费用仍会计费。所以如果一个项目不再使用，务必在 Firebase 控制台里主动删除，而不是放着不管。
免费额度的未来：Google 在收紧吗？
从 2020 到 2024，Firebase 的免费额度没有大幅削减，但有几个信号值得注意。Cloud Functions 的免费额度从"固定 256MB 内存"改为"按配置比例"计算，实际可用调用量变相减少。FCM 开始对非 GMS 设备收费，虽然额度很大，但方向是"扩大收费面"。Firestore 在 2023 年推出了"计数器聚合"功能（Aggregate Queries），count() 和 sum() 的计费是 1 次读取加上一个固定费用，比全量读取文档便宜，这可以解读为 Google 在引导开发者用更省钱的查询模式，也可以解读为他们在为未来的计费精细化铺路。
我个人的观察是，Firebase 的免费层对"验证想法"阶段仍然足够友好，但对"小规模生产"（日活 1,000-10,000）的覆盖越来越薄。很多开发者在这个区间会纠结：继续用 Firebase 但小心优化，还是迁移到更可控的自建后端。这个选择没有标准答案，但前提是你要真正理解自己的用量结构和 Firebase 的计费逻辑，而不是被"免费"两个字蒙蔽到账单来敲门的那天。