Firebase 全应用访问数据库最佳实践及性能影响答疑

单例复用是否为推荐方式 #

全局统一初始化并导出单一Firestore实例供全应用复用，是从v8到v9版本通用的生产环境最佳实践，不需要在每个业务文件里单独初始化数据库引用。
Firebase SDK本身内部已经做了单例缓存逻辑：传入同一个已初始化的Firebase App实例时，无论调用多少次getFirestore(app)，返回的都是同一个底层Firestore实例，不会重复生成核心服务对象。
统一初始化导出的实际收益很明确：

• 所有数据库相关配置（比如离线持久化开关、日志级别、本地缓存大小上限等）可以集中在一处维护，后续调整配置不需要散落在全项目逐文件修改
• 能有效避免误传不同App实例导致的多实例冲突，尤其是多项目接入、多环境切换的场景下，集中管控初始化逻辑的出错概率低很多
• 代码结构更清晰，所有基础第三方服务的初始化逻辑集中存放，后续接手维护的开发者不需要翻遍全项目找服务初始化位置
  只有当你需要在同一个应用内接入多个不同Firebase项目、或者同一个项目下的多个独立数据库实例时，才需要单独初始化对应实例分别导出使用，单库场景完全没必要重复编写初始化逻辑。

不同引用方式的性能影响 #

不同写法的性能差异要分场景判断：

• 如果只是在不同文件里调用getFirestore(app)获取同一个已初始化的实例，因为SDK层直接走缓存返回结果，额外开销只有一次极轻量的函数调用，性能差异完全可以忽略，业务逻辑和终端用户都感知不到区别。
• 如果是每次执行业务函数时，都完整走一遍initializeApp初始化应用再调用getFirestore的全流程，就会引发实际问题：会重复创建底层网络连接、重复初始化鉴权状态、重复占用本地缓存资源，轻则带来不必要的内存开销，重则出现内存泄漏、请求重复发送、离线缓存读写冲突的bug。
• 额外提一个高频踩坑点：在SSR、Serverless这类短生命周期、多请求并发的运行环境里，不要直接把绑定了特定用户鉴权状态的db实例做全局跨请求复用。这不是单例模式本身的问题，是需要按请求上下文做实例隔离——就算你每个文件单独初始化，不做上下文隔离一样会出现跨请求数据串号的问题。

目前生产环境的通用落地方式是单独建立一个类似src/lib/firebase.ts的配置文件，在里面完成Firebase App初始化、所有需要用到的Firebase服务（Firestore、Auth、Storage等）的配置和初始化，之后统一导出这些服务实例，全项目的业务代码直接导入实例使用即可。

内容的提问来源于stack exchange，提问作者PRSHL