Flutter Riverpod中StateNotifierProvider与NotifierProvider的区别及适用场景

核心差异 #

两者都是Riverpod中管理可变状态的provider，但NotifierProvider是Riverpod 2.0+推出的简化方案，核心差异集中在API设计和使用体验上：

1. 基类与初始化逻辑

   • StateNotifierProvider依赖StateNotifier基类，状态必须通过构造函数的super()初始化，比如StateNotifier<int>() : super(0)。
   • NotifierProvider依赖Notifier基类，状态通过build()方法返回初始值，更贴合Riverprovider的生命周期（build会在provider首次被监听时执行）。

2. 样板代码量

   • StateNotifierProvider必须显式指定完整泛型参数（StateNotifierProvider<MyNotifier, MyState>），无法省略。
   • NotifierProvider支持智能类型推导，比如NotifierProvider(MyNotifier.new)可自动推断状态类型，大幅减少冗余代码。

3. 状态更新方式

   • 两者都通过state = newValue实现不可变状态更新，但Notifier无需额外定义State类就能直接处理基本类型、集合等常见状态，写法更简洁。

代码示例对比 #

NotifierProvider 实现计数器

final counterProvider = NotifierProvider<CounterNotifier, int>(CounterNotifier.new);

class CounterNotifier extends Notifier<int> {
  @override
  int build() => 0; // 初始化状态

  void increment() => state++;
  void decrement() => state--;
}

StateNotifierProvider 实现计数器

final counterProvider = StateNotifierProvider<CounterNotifier, int>((ref) => CounterNotifier());

class CounterNotifier extends StateNotifier<int> {
  CounterNotifier() : super(0); // 构造函数初始化状态

  void increment() => state++;
  void decrement() => state--;
}

适用场景 #

优先选择 NotifierProvider

• 新项目或升级到Riverpod 2.0+的项目：官方明确推荐，API更现代简洁，减少冗余代码。
• 状态类型为基本类型（int、String）、集合（List、Map）或简单自定义类：无需额外定义复杂State结构，快速实现状态管理。
• 需配合Riverpod 2.0+新特性：比如和AsyncNotifier无缝处理异步状态，生态支持更完善。

保留使用 StateNotifierProvider

• 维护旧项目：已有大量基于StateNotifierProvider的代码，重构成本高，团队熟悉现有写法。
• 复杂状态管控需求：需要对状态访问和修改做极精细封装（比如限制外部直接读取state），StateNotifier是成熟方案，团队已有经验积累。
• 依赖第三方库：部分工具或库仍依赖StateNotifierAPI，暂时无法切换。

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