3.3 报错与限制：额度、配额与地区问题排查

免费计划与按量计划：能力差异心里要有数

Firebase 的免费计划叫 Spark，绑定结算账号后的按量计划叫 Blaze。两者在产品能力上并不完全对等，有些功能不升级就根本用不了。整体规律是：涉及云函数出网、容器部署、多区域等偏基础设施的能力，基本都在 Blaze 侧；免费计划更适合验证期的原型与小规模应用。

具体哪个产品的哪项能力需要哪个计划，会随平台更新而变化，动手前以控制台里该产品的官方说明为准。经验做法是：立项时就明确项目是否需要 Blaze，避免开发到一半才发现关键能力被计划卡住，被迫中途调整架构。

配额报错的排查顺序

遇到配额或限制类报错，别急着改代码，按固定顺序查：

1. 打开控制台的用量页，看是哪个产品的哪条曲线在异常增长
2. 判断超的是哪一类：读操作、写操作、存储占用还是出站带宽，类别不同，治理手段完全不同
3. 对照报错关键字确认是配额超限还是频率限制，前者靠扩容或优化，后者靠节流和退避
4. 定位到具体业务：哪条查询、哪个监听、哪段代码在消耗用量
5. 决定策略：优化用量、调整架构，还是升级计划

报错文案会随版本变化，遇到陌生提示时，抓关键字而不是背全文。关键字背后的含义通常比字面更宽：比如资源耗尽类报错，既可能是当天配额用完，也可能是单次请求超出限制，要结合用量页交叉确认。另外提醒一句：排查期间保持改动最小，一次只动一个变量，否则治好了也说不清是哪一步起的作用。

地区问题：建库选错 region 的连锁反应

创建 Firestore 或其他带区域属性的资源时选了不合适的 region，影响面比很多人想象的大。

延迟：数据在哪个区域，用户请求就要跑多远。用户集中在东亚而库建在欧美，每次读写的往返延迟都会被放大，实时监听类功能的体验尤其明显。

合规：数据存放地涉及数据驻留要求。面向哪里的用户、受哪里的规则约束，选区之前要把这个问题过一遍，必要时咨询合规团队。

迁移成本：这是最痛的一点。数据库的区域属性创建后不可修改，迁移意味着导出再导入到新库，期间要处理数据一致性、双写过渡或停写窗口，业务越重，成本越高。

处方：新建资源时把 region 当成重要决策对待，按用户分布来选，而不是顺手点了默认值。已经选错的，先评估延迟与合规的实际影响：影响可控就先优化缓存和访问路径缓一缓；影响是实质性的就尽早排迁移计划，拖得越久，数据越多，迁得越贵。

地区选择没有后悔药，这一节的中心思想就一句话：把 region 决策前置，比事后任何补救都便宜。