在Riverpod中，我应使用Provider替代状态为void的Notifier吗？

核心结论 #

用void作为状态的Notifier不算违反规范，但属于「非常规用法」——如果你只是需要暴露一组无状态的函数，直接用常规Provider会更简洁、符合直觉。

具体分析 #

1. void类型Notifier的问题 #

Notifier（比如ChangeNotifier或Riverpod的Notifier）的设计初衷是管理可变更的状态，状态是其核心功能载体。当你把状态设为void，等于完全抛弃了它的核心价值：

• 不需要调用notifyListeners()（因为没有状态要更新），Notifier的监听机制完全无用
• 会让其他开发者困惑——看到Notifier第一反应是有状态要管理，结果发现只是一堆函数，额外增加理解成本

2. 更合适的替代方案：常规Provider #

如果只是要暴露一组工具函数/业务逻辑，直接用Provider提供一个实例即可：

// 示例：用Provider暴露无状态服务类
final myServiceProvider = Provider((ref) => MyService());

class MyService {
  void doBusinessLogic() {
    // 执行同步业务操作
  }

  Future<void> fetchRemoteData() async {
    // 执行异步操作
  }
}

这种方式的优势：

• 完全贴合Provider的设计意图：提供依赖实例，而非状态管理
• 代码逻辑清晰，其他开发者一眼就能明白这是一个无状态的服务类
• 不需要维护Notifier的空状态，减少冗余代码

3. 什么时候适合用Notifier？ #

如果你的函数会伴随状态变更（比如操作后需要更新UI显示的加载状态、错误信息或业务数据），那Notifier才是正确选择：

// 示例：带状态管理的Notifier
final myNotifierProvider = NotifierProvider<MyNotifier, MyState>(MyNotifier.new);

class MyNotifier extends Notifier<MyState> {
  @override
  MyState build() => MyState.initial();

  void doOperation() {
    state = state.copyWith(isLoading: true);
    // 执行核心操作
    state = state.copyWith(isLoading: false, data: operationResult);
  }
}

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