Firebase预留URL导入Auth重复加载firebase-app.js报错排查

• 两份独立firebase-app核心模块重复加载，就是触发Error: Service firestore is not available报错的根本原因。
• Firebase JS SDK采用单核心注册设计：所有服务模块（auth、firestore等）只会在自身依赖的那份firebase-app实例上注册服务能力，不同副本的核心实例之间完全不共享注册信息。
• 你当前场景下的加载错位逻辑：
  • 业务代码手动导入的是/__/firebase/9.8.3/路径下的核心模块
  • 引入的auth、firestore模块内部硬编码了gstatic域名的依赖导入路径，会自动拉取第二份独立的firebase-app核心模块，且auth、firestore服务都注册在这份gstatic来源的核心实例上
  • 用第一份（/__/路径）核心模块的initializeApp方法创建app实例后，传给绑定了第二份核心实例的getFirestore方法时，方法无法识别来自其他核心实例的app对象，直接抛出服务不存在的错误。

无构建场景下最简便的方案是使用原生ES模块的Import Map做路径重写，不需要修改SDK源码、不需要引入打包工具：

1. 在index.html中，在所有业务脚本加载之前加入如下Import Map配置，将gstatic域名下对应版本的Firebase资源路径统一映射到Firebase Hosting预留的本地路径：

<script type="importmap">
{
  "imports": {
    "https://www.gstatic.com/firebasejs/9.8.3/": "/__/firebase/9.8.3/"
  }
}
</script>

2. 原有业务代码不需要做任何修改，配置生效后，浏览器会自动把所有SDK内部硬编码的gstatic导入请求重写到本地/__/路径，整个运行时只会加载一份firebase-app核心实例，服务注册和实例识别逻辑会恢复正常。

• Import Map已在所有现代浏览器中原生支持，无需额外引入polyfill，完全适配纯静态无构建的部署场景。
• 后续如果升级Firebase SDK版本，只需要同步修改Import Map中的版本号，和你使用的/__/firebase/x.y.z/路径版本保持一致即可。
• 不要尝试额外多导入一份firebase-app，该操作会增加核心实例副本数量，进一步加剧加载错位问题。

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