使用Riverpod替代GetIt时如何在main启动阶段初始化RemoteConfig

问题根源 #

Riverpod默认的ProviderScope会在内部创建一个私有状态容器，外部代码无法直接访问这个容器的引用。而main函数中Firebase.initializeApp()的执行位置在Widget树构建之前，拿不到容器的Reader实例，自然无法触发configProvider对应的服务初始化逻辑。

实现步骤 #

1. 提前实例化全局可访问的Provider容器
   已定义的Provider逻辑不需要做任何修改：
   • remoteConfigProvider：返回RemoteConfig实例的Provider
   • configProvider：基于RemoteConfig实例创建ConfigService的Provider
     只需要在全局作用域创建一个可访问的容器实例：

   final providerContainer = ProviderContainer();
   

2. 调整main函数的执行逻辑，在Firebase初始化完成后直接通过容器读取对应服务并执行初始化

   void main() async {
     WidgetsFlutterBinding.ensureInitialized();
     await Firebase.initializeApp();
   
     // 直接读取configProvider，获取ConfigService实例
     final configService = providerContainer.read(configProvider);
     // 执行RemoteConfig的拉取、激活逻辑
     await configService.initialise();
   
     // 绑定提前创建的容器到根Widget，保证全App状态一致
     runApp(
       UncontrolledProviderScope(
         container: providerContainer,
         child: const YourAppRootWidget(),
       ),
     );
   }
   

实现注意点 #

• 传入根Widget时必须使用UncontrolledProviderScope绑定提前创建的providerContainer，不能使用默认无参的ProviderScope，否则会生成两套独立的状态容器，导致App内访问的ConfigService和初始化阶段执行逻辑的服务不是同一实例，出现状态不一致。
• 该实现完全保留Riverpod的依赖注入能力，不会引入硬编码单例带来的测试困难、依赖混乱问题，所有服务的依赖关系依然由Riverpod统一管理。
• 整个初始化流程严格按照执行顺序同步完成：先完成Firebase初始化、再执行RemoteConfig的拉取激活，最后才渲染根Widget，可以避免Widget初次渲染时因为RemoteConfig未初始化完成出现的默认值闪烁问题。

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