PAYATHON 2026

Flutter Web 初始化 Firebase 时为何提示未创建默认应用?

数据小许

先统一 Firebase 的初始化方式

现有 main.dart 已经在 runApp() 之前等待 Firebase.initializeApp(),初始化顺序本身没有明显问题。应优先检查 index.html:它手动加载并初始化了 Firebase JavaScript SDK 8.10.0,而错误堆栈来自 12.9.0。

对于采用 FlutterFire 默认 Web 加载方式的项目,建议移除 HTML 中的旧版 Firebase 脚本及初始化代码,由 FlutterFire 加载所需 SDK,并在 Dart 中完成初始化。Firebase 官方文档说明,FlutterFire 默认会在 Web 平台自动注入 Firebase JavaScript SDK。参考官方 Web 配置说明。

这两个版本同时出现值得优先排查,但仅凭当前片段,还不能确认它就是唯一根因。

为什么调用过 initializeApp 仍会报错?

app/no-app 表示执行该次应用查找时,当前 SDK 中没有可用的默认应用 [DEFAULT]。

HTML 中的 firebase.initializeApp(firebaseConfig) 属于手动引入的 8.10.0 SDK。它执行过,不能证明 FlutterFire 当前使用的 SDK 中也已创建默认应用。即使 Dart 中写了初始化调用,也需要确认它实际成功完成,且没有其他代码提前访问 Firebase。

因此,不能仅凭报错就判断是忘记写了 initializeApp()。需要核对 SDK 加载来源、初始化是否成功,以及首次访问 Firebase 的位置。

1. 移除 index.html 中的旧版 Firebase 配置

在 web/index.html 中删除问题里列出的四个 Firebase 8.10.0 <script> 标签,以及包含以下内容的整个初始化脚本块:

var firebaseConfig = {
  // ...
};
firebase.initializeApp(firebaseConfig);

保留项目现有的 Flutter 启动脚本。

这项调整以项目通过 FlutterFire 使用 Firebase 为前提。如果页面还有独立调用 firebase.auth()、firebase.firestore() 等旧版 JavaScript API 的业务代码,也需要检查并迁移;直接移除脚本会影响这些调用。

2. 核对 Web 配置并在 Dart 中初始化

手写 FirebaseOptions 不一定有错,但当前配置值都是 xxx,无法判断实际参数是否正确。可以使用 FlutterFire CLI 生成配置,降低平台或应用参数填错的可能。

如果尚未安装相关工具,先安装 Firebase CLI,然后执行:

firebase login
dart pub global activate flutterfire_cli

在 Flutter 项目根目录运行:

flutterfire configure

选择正确的 Firebase 项目,并勾选 Web 平台。生成 lib/firebase_options.dart 后,按下面的方式调整入口;保留现有 MyApp 定义及其所需 import:

import 'package:flutter/material.dart';
import 'package:firebase_core/firebase_core.dart';
import 'firebase_options.dart';

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  final app = await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );

  debugPrint('Firebase initialized: ${app.name}');
  runApp(const MyApp());
}

这是 Firebase 官方提供的 Flutter 初始化流程。也可以继续手写 FirebaseOptions,但参数应来自目标 Firebase Web 应用,示例中的 xxx 需要替换为真实配置。参考官方初始化指南。

3. 完整重启后检查结果

停止当前运行,再启动 Web 应用:

flutter run -d chrome

修改 HTML 脚本后,应完整刷新页面,不能仅依赖 Hot Reload。检查浏览器实际加载的页面,确认手动添加的 8.10.0 脚本已经移除。

如果仍然报错,按以下顺序继续定位:

  1. 查看初始化日志是否输出。如果没有输出,检查 Firebase.initializeApp() 的异常及其之前的控制台错误。不要捕获异常后继续启动依赖 Firebase 的业务页面。
  2. 检查是否提前访问 Firebase。留意启动服务、依赖注入和全局对象中对 Firebase.app()、FirebaseAuth.instance、FirebaseFirestore.instance 的访问,确保它们发生在初始化完成之后。
  3. 检查实际依赖版本。查看 pubspec.yaml 和 pubspec.lock 中的 firebase_core、firebase_core_web 及其他 FlutterFire 插件,特别注意是否存在手动添加的 dependency_overrides。
  4. 核对报错环境。如果修改后仍加载已删除的旧脚本,检查浏览器缓存、Service Worker 或部署产物是否仍在提供旧页面。

堆栈中出现 12.9.0,并不意味着应该把 HTML 中所有 URL 直接改为这个版本。先恢复 FlutterFire 默认加载方式,再根据实际依赖和初始化异常继续排查,更容易确认问题来源。

备注:内容仅供参考。