如何在普通类或build方法外部使用Riverpod？

首先明确两个核心规则：

• Riverpod的所有Provider需要定义为全局顶层常量/变量，不要在业务类内部重复创建，重复创建会生成独立的状态实例，无法访问全局统一维护的状态
• Riverpod的状态访问本质依赖Ref对象或根节点的ProviderContainer实例，普通类不需要继承任何Riverpod基类，只需要在初始化时拿到对应引用即可正常读写状态。

前置修正：统一全局Provider定义 #

先将用户状态的Provider移到文件顶层，不要放在任何类内部：

// user_provider.dart 顶层代码
final userProvider = StateNotifierProvider<UserProvider, User>((ref) => UserProvider());

你现有的User数据模型、UserProvider状态类不需要做任何修改，保持原有写法即可。

方案1：构造函数传入Ref（Flutter业务场景首选） #

如果你的业务类（比如示例中的FirestoreMethods）是在Flutter界面层逻辑中使用，最规范的写法是给业务类本身也创建一个全局Provider，初始化时自动将Ref注入到类中，类内部就可以和Widget上下文里一样自由访问所有Provider状态。
修改后的FirestoreMethods代码：

import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';
import '../providers/user_provider.dart';
import '../models/user.dart' as model;

// FirestoreMethods的全局Provider，初始化时自动传入ref
final firestoreMethodsProvider = Provider<FirestoreMethods>((ref) {
  return FirestoreMethods(ref: ref);
});

class FirestoreMethods {
  final FirebaseFirestore _firestore = FirebaseFirestore.instance;
  // 持有Ref引用
  final Ref ref;

  // 构造函数要求传入ref实例
  FirestoreMethods({required this.ref});

  // 示例业务方法
  Future<void> fetchUserData() async {
    // 直接通过ref读取用户状态，和build方法中的写法完全一致
    final currentUser = ref.read(userProvider);
    print(currentUser.email);
    print(currentUser.uid);
    print(currentUser.username);

    // 需要更新状态时，直接取notifier调用方法即可
    // ref.read(userProvider.notifier).addUser(newUser);

    // Firestore业务逻辑正常编写即可
    // final res = await _firestore.collection('users').doc(currentUser.uid).get();
  }
}

在Widget中使用时，不需要手动实例化FirestoreMethods，直接通过ref获取即可：

// 在ConsumerWidget/ConsumerStatefulWidget的build方法中
final firestoreMethods = ref.watch(firestoreMethodsProvider);
// 调用业务方法时，类内部已经可以正常访问Riverpod状态
firestoreMethods.fetchUserData();

方案2：传入ProviderContainer（纯Dart/脱离Widget树场景适用） #

如果需要在完全脱离Flutter Widget树的场景使用（比如后台Isolate、纯Dart脚本、应用入口初始化逻辑），可以直接传入Riverpod根节点的ProviderContainer实例，它的状态读写能力和Ref完全一致。
应用入口初始化示例：

void main() {
  // 初始化全局容器
  final container = ProviderContainer();
  // 初始化业务类时传入容器
  final firestoreMethods = FirestoreMethods(container: container);
  
  runApp(
    UncontrolledProviderScope(
      container: container,
      child: const MyApp(),
    ),
  );
}

对应修改FirestoreMethods：

class FirestoreMethods {
  final FirebaseFirestore _firestore = FirebaseFirestore.instance;
  final ProviderContainer container;

  FirestoreMethods({required this.container});

  Future<void> fetchUserData() async {
    // 用container.read替代ref.read即可，用法完全一致
    final currentUser = container.read(userProvider);
    print(currentUser.email);
  }
}

避坑提示 #

• 不要在普通类中重复创建ProviderScope或重复定义同名Provider，会导致状态隔离，无法获取全局统一的状态值
• 如果需要在类内部持续监听状态变化，可以直接调用ref.listen/container.listen传入回调，和Widget内的监听逻辑完全一致
• 临时调用的场景也可以在方法调用时把ref作为参数传入，但长期维护的聚合业务类不推荐这种写法，会提升代码耦合度。

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