3.4 国内使用 Firebase：网络、可用性与合规现实

先说清楚网络这一层的现实

Firebase 各项服务依赖 Google 的基础设施，而 Google 服务在国内网络的可用性长期存在波动。这意味着两件事：设备层面，开发与使用通常需要自行解决网络连通性问题；面向公众提供服务，则涉及企业合规使用的自行评估。本书只陈述现实、讨论架构思路，不提供也不讨论任何绕过手段，相关责任在使用方自己。

把这层现实摆在最前面的目的不是劝退，而是让架构决策建立在真实约束之上：网络可用性是一个不可控变量，核心业务链路不应该押在不可控变量上。这个判断不针对 Firebase 一家，任何在当前环境下可达性无法自主保障的服务都适用。

面向国内用户：核心链路为什么不适合押在 Firebase 上

对国内用户为主的 App，下面几条链路的风险要单独评估：

核心链路的特点是：一旦挂掉就是事故。把登录、推送、交易这类主路径放在网络可达性无法保障的服务上，等于把业务稳定性外包给了环境。次要链路则宽松得多——数据分析、崩溃统计、A/B 实验这类即便短时不可用也不影响用户主流程的能力，不少团队仍在使用，丢的只是部分数据点，不是用户。

双轨制：一个被反复验证过的思路

实践中比较稳妥的做法，是按用户所在地区分轨：

• 国内用户走国内方案：国产 BaaS 平台或自建后端，推送走厂商通道，登录走国内身份服务
• 海外用户走 Firebase：认证、数据库、云函数、分析照常用，生态成熟，开发效率高
• 业务层做抽象：数据访问、推送、登录的接口定义保持统一，底层两套实现按环境切换
• 数据边界划清：两边各自闭环，避免频繁跨境同步带来延迟与合规的双重压力

双轨的代价是维护两套基础设施，运营成本肉眼可见地增加，业务代码必须保持抽象干净，否则越写越乱。如果产品明确只服务一个市场，那就单轨走到底，不必为了技术栈统一硬做兼容。此外还有折中形态：以海外为主、少量国内用户的产品，可以主体继续用 Firebase，只把登录与推送两条链路单独换成国内方案，改动面最小。

合规提醒：这部分不能省

面向国内提供互联网服务，涉及服务器与数据时至少要关注三类要求：数据出境的评估要求、互联网服务的备案要求、用户数据本地化存储的要求。这类规则更新频繁，执行口径也在变化，本节不展开具体条文，动手前请以最新法规与平台政策为准，必要时咨询法务或合规团队。技术方案的选型可以迭代，合规问题却往往没有重来的机会，这一项建议前置而不是补课。

用户在哪里，建议怎么选

表格只是起点。最终方案要结合团队技术栈、预算、合规要求与产品节奏综合判断，唯一不建议的是明知约束存在还把核心链路硬押上去。选型可以迭代，核心链路的大迁移代价最高，这一步值得多花时间想清楚。