Flutter应用初始化时将Firestore层级数据加载至Provider后routes为空如何解决

1. Provider实例被反复销毁重建，数据无法持久绑定 #

当前代码把ChangeNotifierProvider.value写在LoadingScreen的build方法内部，这是最核心的问题：

• Widget的build方法会在每次触发重建时重新执行，意味着每次LoadingScreen刷新，都会执行value: AppData()创建一个全新的AppData实例
• 首次创建的AppData实例虽然会正常执行_loadData逻辑、从Firestore拉取到完整数据，但这个实例一旦因为重建被替换，就会从Widget树中移除，它发出的状态更新根本无法传递到当前绑定的Consumer上
• 调试时能观察到仓库层正常返回数据，本质是某个临时创建的AppData实例完成了加载流程，但UI最终绑定的是最新被创建的、还没执行完加载逻辑的新实例，所以看到的routes永远是空值。

2. 嵌套异步遍历的实现存在稳定性隐患 #

仓库层所有嵌套查询中使用的Future.forEach是并行触发所有子项查询的写法，在三层嵌套的场景下，单次启动可能会同时发起几十甚至上百个Firestore请求，很容易触发Firestore的请求频率限制，或者出现单个请求异常直接打断整个加载流程的问题。

3. 状态判断边界缺失 #

用routes != null作为加载完成的判断依据存在明显缺陷，如果_loadData执行过程中抛出任何异常，_routes永远不会被赋值，应用会永久卡在启动页，没有错误提示和重试入口。

第一步：全局注入唯一的AppData实例 #

把Provider的位置从LoadingScreen内部上移到Widget树顶层，保证整个应用生命周期内只有一个AppData实例，不会因为重建被替换：

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await Firebase.initializeApp();
  // 在应用入口全局注入Provider，实例仅创建一次
  runApp(
    ChangeNotifierProvider(
      create: (context) => AppData(),
      child: const App(),
    )
  );
}

调整后，LoadingScreen不再需要自己创建Provider，直接通过Consumer获取全局唯一的AppData实例即可。

第二步：重构AppData的状态管理逻辑 #

增加明确的加载状态标记，替代原来用routes是否为null判断加载进度的写法，同时补上异常捕获和重试能力：

class AppData with ChangeNotifier {
  static final FirebaseRepo _repo = FirebaseRepo();
  List<model.Route> _routes = [];
  bool _isLoading = true;
  Object? _loadError;

  // 暴露不可变状态给UI层，避免外部直接修改内部数据
  bool get isLoading => _isLoading;
  Object? get loadError => _loadError;
  List<model.Route> get routes => List.unmodifiable(_routes);

  AppData() {
    _loadData();
  }

  Future<void> _loadData() async {
    _isLoading = true;
    _loadError = null;
    notifyListeners();
    try {
      // 拉取全量数据
      _routes = await _repo.findAllRoutes();
    } catch (e) {
      _loadError = e;
    } finally {
      _isLoading = false;
      notifyListeners();
    }
  }

  // 暴露重试方法供UI调用
  void retryLoad() => _loadData();
}

第三步：修正仓库层的遍历逻辑 #

把原来的Future.forEach替换为普通for循环搭配await的串行加载写法，减少并发请求数量，同时保证每一层的子项都能严格加载完成再返回上层：

Future<List<model.Route>> findAllRoutes() async {
  final routes = <model.Route>[];
  final routeContent = await _db.collection('content')
      .where("type", isEqualTo: "route")
      .orderBy("order", descending: false)
      .get(GetOptions(source: _dbSource));

  // 串行遍历每个路线，等待每个路线的所有房间、POI加载完成
  for (final snapshot in routeContent.docs) {
    final route = await loadRouteFromSnapshot(snapshot);
    route.rooms = await findRouteRooms(route.id);
    routes.add(route);
  }
  return routes;
}

findRouteRooms和findRoomPois方法也要做同样的替换，把原来的Future.forEach改成普通for循环+await的写法，保证异步流程的稳定性。

第四步：调整LoadingScreen的UI分支逻辑 #

基于专门的加载状态做不同的UI渲染，覆盖加载中、加载失败、加载完成三种场景：

class LoadingScreen extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Consumer<AppData>(
      builder: (context, provider, child) {
        // 加载中显示启动页
        if (provider.isLoading) {
          return Stack(
            children: [
              Container(
                alignment: Alignment.center,
                color: Colors.white,
                child: Image.asset('assets/img/splash_background.png'),
              ),
              Container(
                alignment: const Alignment(0.0, 0.0),
                child: Image.asset(
                  'assets/img/icon.png',
                  height: 200,
                  width: 200,
                ),
              )
            ],
          );
        }
        // 加载失败显示错误提示和重试按钮
        if (provider.loadError != null) {
          return Center(
            child: Column(
              mainAxisSize: MainAxisSize.min,
              children: [
                const Text("数据加载失败，请检查网络连接"),
                const SizedBox(height: 16),
                ElevatedButton(
                  onPressed: () => provider.retryLoad(),
                  child: const Text("重新加载"),
                )
              ],
            ),
          );
        }
        // 加载完成进入首页
        return const Home();
      },
    );
  }
}

• 不要在Widget的build方法内创建ChangeNotifier实例，build方法可能会被高频触发，频繁创建实例会直接导致状态丢失
• 全量加载的方式仅适合数据量较小的静态场景，如果后续数据规模增长，要结合Firestore的本地缓存策略设置合理的过期时间，避免每次冷启动都拉取全量服务端数据
• 暴露给外部的routes列表建议使用List.unmodifiable包装，避免外部代码直接修改内部存储的数据，引发不可预期的状态异常

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