Flutter：路由守卫中用WidgetRef还是ProviderRef读取Riverpod？

问题背景 #

我目前用两种Ref读取Riverpod Provider：

• WidgetRef：用于build方法内，触发组件重建
• ProviderRef：用于非Widget生命周期的任意场景

同时我用auto_route包实现路由并创建了多个路由守卫，相关代码如下：

AppRouter代码 #

@AutoRouterConfig()
class AppRouter extends _$AppRouter {
  AppRouter(this.ref) : super();

  WidgetRef ref;

  @override
  List<AutoRoute> get routes => [
        AutoRoute(
          page: OnboardingRoute.page,
          guards: [OnboardingGuard(ref)],
          // initial: true,
        ),
        AutoRoute(
          page: AuthRoute.page,
          initial: true,
        ),
        AutoRoute(
          page: HomeRoute.page,
          guards: [AuthGuard(ref)],
        ),
      ];
}

app.dart代码 #

class App extends ConsumerWidget {
  const App({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final themeMode = ref.watch(themeRepositoryProvider).requireValue.themeMode;

    return MaterialApp.router(
      routerConfig: AppRouter(ref).config(),
      themeMode: themeMode,
      theme: appThemeData,
      darkTheme: appThemeDataDark,
      debugShowCheckedModeBanner: false,
    );
  }
}

AuthGuard代码 #

class AuthGuard extends AutoRouteGuard {
  AuthGuard(this.ref) : super();

  WidgetRef ref;

  @override
  void onNavigation(NavigationResolver resolver, StackRouter router) async {
    final isLoggedIn = ref.watch(authProvider);

    if (!isLoggedIn) {
      router.push(AuthRoute(initial: AuthPages.login));
    } else {
      resolver.next(true);
    }
  }
}

当前疑问 #

我在app.dart中将WidgetRef通过构造函数传给AppRouter，再转发给路由守卫，以此读取Provider值实现条件导航。请问这种方式是否可行？是否应改为注入ProviderRef？对此方案有何建议或负面反馈？

解答 #

1. 现有方式的可行性 #

这种方式是可行的，但存在一些潜在问题：

• WidgetRef绑定的是ConsumerWidget的生命周期，当AppWidget重建时（比如主题切换、依赖的Provider更新），会重新创建AppRouter实例，进而重新创建所有路由守卫。虽然auto_route通常能处理这种情况，但频繁重建可能带来不必要的开销。
• 在守卫的onNavigation里用ref.watch，如果authProvider更新，守卫本身不会触发任何重建（因为守卫不是Widget），这意味着只有当导航事件发生时才会读取最新值——这其实符合守卫的需求，因为守卫只需要在导航瞬间判断状态，不需要实时响应状态变化。

2. 是否需要改为ProviderRef？ #

不建议直接用ProviderRef，建议改为使用ProviderContainer（可通过ref.container从WidgetRef中获取）：

• ProviderRef是给Provider内部使用的，用于创建其他Provider、监听生命周期，不适合在外部（比如路由守卫）直接调用。
• 改用ProviderContainer的优化代码示例：

  // 修改AuthGuard
  class AuthGuard extends AutoRouteGuard {
    AuthGuard(this.container) : super();
  
    final ProviderContainer container;
  
    @override
    void onNavigation(NavigationResolver resolver, StackRouter router) async {
      // 守卫仅需导航瞬间的状态，用read更合适，避免不必要的监听
      final isLoggedIn = container.read(authProvider);
  
      if (!isLoggedIn) {
        router.push(AuthRoute(initial: AuthPages.login));
      } else {
        resolver.next(true);
      }
    }
  }
  
  // 修改AppRouter
  @AutoRouterConfig()
  class AppRouter extends _$AppRouter {
    AppRouter(this.container) : super();
  
    final ProviderContainer container;
  
    @override
    List<AutoRoute> get routes => [
          AutoRoute(
            page: OnboardingRoute.page,
            guards: [OnboardingGuard(container)],
          ),
          AutoRoute(page: AuthRoute.page, initial: true),
          AutoRoute(page: HomeRoute.page, guards: [AuthGuard(container)]),
        ];
  }
  
  // 修改app.dart
  class App extends ConsumerWidget {
    const App({super.key});
  
    @override
    Widget build(BuildContext context, WidgetRef ref) {
      final themeMode = ref.watch(themeRepositoryProvider).requireValue.themeMode;
  
      return MaterialApp.router(
        routerConfig: AppRouter(ref.container).config(),
        themeMode: themeMode,
        theme: appThemeData,
        darkTheme: appThemeDataDark,
        debugShowCheckedModeBanner: false,
      );
    }
  }
  

  这样做的好处：
  • ProviderContainer是全局稳定的（除非手动创建多个），不会随Widget重建而变化，避免了路由守卫的频繁重建。
  • 用container.read更贴合守卫的使用场景，不会注册无用的状态监听，减少资源浪费。

3. 其他建议 #

• 如果authProvider是异步类型（比如FutureProvider），记得用await container.read(authProvider.future)确保获取到最终的登录状态，避免读取到初始的未完成状态。
• 可以把路由守卫的创建逻辑封装到Provider中，进一步解耦：

  final authGuardProvider = Provider((ref) => AuthGuard(ref.container));
  

  之后在AppRouter里通过ref.read(authGuardProvider)获取守卫即可。
• 尽量不要在守卫中使用watch，如果确实需要监听状态变化，要注意清理监听（但auto_route守卫没有明确的销毁回调，所以优先用read）。

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