Flutter 状态管理详解

1. 状态管理基础概念

1.1 什么是”状态”

在 Flutter 中，状态（State） 指的是在 widget 生命周期内可能发生变化、并且变化后需要触发 UI 重新渲染的数据。

状态可以分为两大类：

类型	说明	举例
临时状态（Ephemeral State / Local State）	只在单个 widget 内部使用，不需要跨 widget 共享	TextField 的输入内容、动画进度、当前选中的 Tab
应用状态（App State / Shared State）	需要在多个 widget、多个页面之间共享	用户登录信息、购物车数据、主题模式、网络请求结果

Flutter 官方的经验法则：

临时状态用 StatefulWidget + setState 即可。
应用状态需要引入某种”状态管理方案”，让状态与 UI 解耦，实现跨组件共享和精确更新。

1.2 为什么需要状态管理方案

Flutter 的 UI 是”响应式”的：Widget 是不可变的（immutable），UI 是状态的函数：

UI = f(State)

当状态变化时，Flutter 需要一种机制来：

通知依赖该状态的 widget 需要重建（rebuild）；
精确定位到哪些 widget 需要重建，避免全树重建带来的性能损耗；
跨层级传递状态，避免”prop drilling”（逐层传参）。

状态管理框架的核心工作，本质上就是解决这三个问题。

1.3 状态管理的核心模式

绝大多数 Flutter 状态管理方案，都是下面几种模式的变体或组合：

观察者模式（Observer）：状态对象持有监听者列表，状态变化时通知所有监听者。（ChangeNotifier、MobX、Riverpod 的部分实现）
发布-订阅 / Stream：状态变化通过 Stream 广播出去，UI 通过 StreamBuilder 订阅。（Bloc、RxDart）
依赖注入 + InheritedWidget：把状态”挂”在 widget 树上某个节点，子孙节点通过 context 查找并订阅。（Provider、Riverpod）
单向数据流（Unidirectional Data Flow）：UI 派发 Action/Event → 状态容器处理 → 产生新 State → UI 重新渲染。（Redux、Bloc）

2. setState —— 最原始的状态管理

setState 是 Flutter 最基础的状态更新机制，适用于局部、临时状态。

class CounterPage extends StatefulWidget {
  const CounterPage({super.key});

  @override
  State<CounterPage> createState() => _CounterPageState();
}

class _CounterPageState extends State<CounterPage> {
  int _count = 0;

  void _increment() {
    setState(() {
      _count++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('$_count'),
        ElevatedButton(onPressed: _increment, child: const Text('+1')),
      ],
    );
  }
}

原理

setState 会标记当前 Element 为 dirty，并在下一帧调用 build() 方法重新构建。
重建范围仅限于调用 setState 的 State 对象所对应的子树，不会影响父级或兄弟节点。

局限性

状态和 UI 强耦合，无法跨 widget 共享。
一旦状态需要跨越多层 widget 传递，就会出现”逐层传参”问题。
不便于测试（状态逻辑和 UI 逻辑混在一起）。
大范围 rebuild 容易造成性能浪费（哪怕只有一小块 UI 需要更新，也会重建整个 build 方法覆盖的子树）。

3. InheritedWidget / InheritedModel —— Flutter 状态管理的基石

几乎所有主流状态管理框架（Provider、Riverpod 等）底层都依赖 InheritedWidget。

3.1 基本原理

InheritedWidget 是 Flutter 提供的一种特殊 widget，允许子孙节点通过 BuildContext 高效地访问祖先节点持有的数据，而不需要一层层传递构造函数参数。

class CounterInherited extends InheritedWidget {
  final int count;
  final VoidCallback increment;

  const CounterInherited({
    super.key,
    required this.count,
    required this.increment,
    required super.child,
  });

  static CounterInherited of(BuildContext context) {
    final result =
        context.dependOnInheritedWidgetOfExactType<CounterInherited>();
    assert(result != null, 'No CounterInherited found in context');
    return result!;
  }

  @override
  bool updateShouldNotify(CounterInherited oldWidget) {
    return oldWidget.count != count;
  }
}

关键点：

context.dependOnInheritedWidgetOfExactType<T>()：子孙 widget 调用此方法后，会被注册为该 InheritedWidget 的依赖者。
当 InheritedWidget 重建时，Flutter 会调用 updateShouldNotify() 判断是否需要通知依赖者；如果返回 true，所有依赖它的 Element 会被标记为 dirty 并重建。
这是一种”按需精确通知”机制：只有真正调用了 of(context) 的 widget 才会被重建，而不是整棵子树。

3.2 InheritedModel

InheritedModel 是 InheritedWidget 的进阶版本，支持按”字段（aspect）“粒度通知，进一步减少不必要的 rebuild。适合状态对象里有多个独立字段、只想让关心某个字段的 widget 重建的场景。

3.3 局限性

原生 API 较为繁琐（需要手写 of()、updateShouldNotify()）。
无法很好地承载”业务逻辑”（它更像是一个数据管道，而不是完整的状态容器）。
因此实践中很少直接裸用，通常是被 Provider 等库封装后使用。

4. ValueNotifier / ChangeNotifier

这是 Flutter SDK 自带的、轻量级的”可监听对象”，是 Provider 等库的基础构件。

4.1 ChangeNotifier

class CounterModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;

  void increment() {
    _count++;
    notifyListeners(); // 通知所有监听者
  }
}

配合 AnimatedBuilder 或 ListenableBuilder 使用，不依赖任何第三方库：

final counter = CounterModel();

ListenableBuilder(
  listenable: counter,
  builder: (context, child) => Text('${counter.count}'),
)

4.2 ValueNotifier

ValueNotifier<T> 是 ChangeNotifier 的简化版，专门用于监听单一值：

final ValueNotifier<int> counter = ValueNotifier<int>(0);

ValueListenableBuilder<int>(
  valueListenable: counter,
  builder: (context, value, child) => Text('$value'),
)

// 更新
counter.value++; // 自动触发 notifyListeners

特点

优点：轻量、无需引入第三方依赖、性能好（ValueListenableBuilder 只重建自己包裹的子树）。
缺点：适合简单场景；复杂的依赖注入、跨页面共享、测试便利性等方面不如 Provider/Riverpod 完善。

5. Provider

provider 是官方长期推荐的状态管理库（对 InheritedWidget 的封装），也是最主流的入门方案之一。

5.1 核心 API

API	作用
`ChangeNotifierProvider`	创建并向下提供一个 `ChangeNotifier` 实例
`Provider`	提供任意不变对象（不需要监听变化）
`Provider.value`	提供一个已存在的对象（常用于 Widget 树中间插入）
`MultiProvider`	同时注册多个 Provider，避免嵌套过深
`Consumer<T>`	在 widget 树中订阅并按需重建
`Selector<T, S>`	只订阅对象中的某个字段，实现更细粒度的重建控制
`context.watch<T>()`	在 `build` 中订阅（等价于 Consumer）
`context.read<T>()`	只读取一次，不订阅（常用于事件回调中）

5.2 示例

class CounterModel extends ChangeNotifier {
  int _count = 0;
  int get count => _count;
  void increment() {
    _count++;
    notifyListeners();
  }
}

void main() {
  runApp(
    ChangeNotifierProvider(
      create: (_) => CounterModel(),
      child: const MyApp(),
    ),
  );
}

class CounterText extends StatelessWidget {
  const CounterText({super.key});
  @override
  Widget build(BuildContext context) {
    final count = context.watch<CounterModel>().count; // 订阅，count 变化时重建
    return Text('$count');
  }
}

class IncrementButton extends StatelessWidget {
  const IncrementButton({super.key});
  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () => context.read<CounterModel>().increment(), // 只调用方法，不订阅
      child: const Text('+1'),
    );
  }
}

5.3 精细化重建：Selector

Selector<UserModel, String>(
  selector: (context, user) => user.name, // 只关心 name 字段
  builder: (context, name, child) => Text(name),
)

即使 UserModel 里的其它字段（如 age）变化，只要 name 没变，Selector 包裹的部分就不会重建。

5.4 优缺点

优点：

学习曲线平缓，官方推荐，生态成熟。
基于 InheritedWidget，性能可控。
Selector 可以做到字段级别的精确刷新。

缺点：

依赖 BuildContext，在某些场景（如无 context 环境）使用不便。
编译期无法检查 Provider 是否存在，出错时是运行时异常（如 ProviderNotFoundException）。
多个 Provider 之间存在依赖关系时（ProxyProvider）写法较繁琐。

6. Riverpod

Riverpod 由 Provider 的作者重新设计而成，目标是解决 Provider 的痛点：去除对 BuildContext 的依赖、支持编译期安全、更好的可测试性。

6.1 核心概念

概念	说明
`Provider`	提供一个只读、不变的值
`StateProvider`	提供一个可变的简单状态（如 int、bool）
`StateNotifierProvider` / `NotifierProvider`	提供带业务逻辑的复杂状态对象
`FutureProvider`	提供异步数据（自动处理 loading/error/data 三态）
`StreamProvider`	提供 Stream 数据
`ref.watch()`	订阅并在数据变化时重建
`ref.read()`	只读取一次
`ref.listen()`	监听变化并执行副作用（不触发 rebuild）
`ProviderScope`	整个应用的 Provider 容器（取代 Provider 库中散落的 `MultiProvider`）

6.2 示例（Riverpod 2.x，使用代码生成）

part 'counter_provider.g.dart';

@riverpod
class Counter extends _$Counter {
  @override
  int build() => 0;

  void increment() => state++;
}

void main() {
  runApp(const ProviderScope(child: MyApp()));
}

class CounterText extends ConsumerWidget {
  const CounterText({super.key});
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final count = ref.watch(counterProvider); // 订阅
    return Text('$count');
  }
}

class IncrementButton extends ConsumerWidget {
  const IncrementButton({super.key});
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ElevatedButton(
      onPressed: () => ref.read(counterProvider.notifier).increment(),
      child: const Text('+1'),
    );
  }
}

6.3 异步状态处理（对比手写 FutureBuilder 的优势）

@riverpod
Future<List<Post>> posts(PostsRef ref) async {
  final repo = ref.watch(postRepositoryProvider);
  return repo.fetchPosts();
}

// UI 中
final postsAsync = ref.watch(postsProvider);
postsAsync.when(
  data: (posts) => ListView(children: posts.map((p) => Text(p.title)).toList()),
  loading: () => const CircularProgressIndicator(),
  error: (err, stack) => Text('Error: $err'),
);

6.4 优缺点

优点：

不依赖 BuildContext，可以在任意 Dart 代码（甚至非 Flutter 环境）中使用。
编译期类型安全，Provider 缺失会在编译期或明确的运行时报错，而非隐晦的 context 查找失败。
内建对异步状态（Future/Stream）的一等支持，AsyncValue 自动处理 loading/error/data。
天然支持依赖覆盖（overrideWith），非常利于单元测试和 Mock。
Provider 之间可以互相 watch，自动处理依赖链更新，替代 Provider 库中繁琐的 ProxyProvider。

缺点：

学习曲线比 Provider 陡峭，尤其是代码生成（riverpod_generator）部分需要额外配置 build_runner。
概念较多（Provider 种类多），初期容易混淆。

7. Bloc / Cubit

flutter_bloc 是基于单向数据流和**响应式编程（Stream）**思想的状态管理框架，强调”业务逻辑与 UI 完全分离”，在中大型企业级项目中很受欢迎。

7.1 核心概念

Event（事件）：描述”发生了什么”，由 UI 派发。
State（状态）：描述”UI 应该长什么样”，由 Bloc 产出。
Bloc：接收 Event，通过 on<Event> 注册处理函数，处理后 emit 新的 State。
Cubit：Bloc 的简化版，没有 Event 概念，直接调用方法 emit 新状态，适合逻辑简单的场景。

7.2 Cubit 示例（简化版）

class CounterCubit extends Cubit<int> {
  CounterCubit() : super(0);
  void increment() => emit(state + 1);
}

BlocProvider(
  create: (_) => CounterCubit(),
  child: BlocBuilder<CounterCubit, int>(
    builder: (context, count) => Text('$count'),
  ),
);

// 触发
context.read<CounterCubit>().increment();

7.3 Bloc 示例（完整事件驱动模型）

// 定义事件
sealed class CounterEvent {}
class IncrementPressed extends CounterEvent {}
class DecrementPressed extends CounterEvent {}

// Bloc
class CounterBloc extends Bloc<CounterEvent, int> {
  CounterBloc() : super(0) {
    on<IncrementPressed>((event, emit) => emit(state + 1));
    on<DecrementPressed>((event, emit) => emit(state - 1));
  }
}

BlocProvider(
  create: (_) => CounterBloc(),
  child: BlocBuilder<CounterBloc, int>(
    builder: (context, state) => Text('$state'),
  ),
);

// 触发
context.read<CounterBloc>().add(IncrementPressed());

7.4 常用配套组件

组件	作用
`BlocBuilder`	根据 state 变化重建 UI
`BlocListener`	监听 state 变化执行副作用（弹窗、路由跳转），不重建 UI
`BlocConsumer`	`BlocBuilder` + `BlocListener` 的组合
`MultiBlocProvider`	同时注册多个 Bloc/Cubit
`BlocSelector`	类似 Provider 的 Selector，只订阅 state 的某个字段

7.5 优缺点

优点：

强制业务逻辑与 UI 分离，代码结构统一、可测试性极强（bloc_test 库可以对状态流做断言）。
单向数据流清晰，适合团队协作和大型项目，便于追踪状态变化历史（配合 BlocObserver 可以打印每次状态转移日志，非常利于调试）。
与 Stream 生态（如 RxDart）结合紧密。

缺点：

样板代码较多（尤其是完整 Event/State 建模），小项目容易”杀鸡用牛刀”。
学习曲线较陡，需要理解 Stream、事件驱动等概念。

8. GetX

GetX 是一个”全家桶”式框架，集状态管理 + 路由管理 + 依赖注入于一体，以简洁著称。

8.1 响应式状态示例

class CounterController extends GetxController {
  var count = 0.obs; // 响应式变量
  void increment() => count++;
}

final controller = Get.put(CounterController());

Obx(() => Text('${controller.count}')); // 自动订阅 count

ElevatedButton(
  onPressed: controller.increment,
  child: const Text('+1'),
);

8.2 优缺点

优点：

API 极简，几乎没有样板代码，上手速度快。
内建路由管理（Get.to()）和依赖注入（Get.put() / Get.find()），不需要 BuildContext。
性能较好（.obs 底层基于精细的响应式监听）。

缺点：

“魔法”较多（全局单例、隐式依赖），大型项目中可能导致代码可读性和可维护性下降。
与 Flutter 官方推荐路线耦合度低，社区对其架构设计存在一些争议（例如过度依赖全局状态、测试隔离性较差）。
版本更新中 API 变动较多，需要留意兼容性。

9. MobX

mobx 是从前端 MobX（JS）移植而来的响应式状态管理库，核心理念是”任何能从状态派生的东西，都应该自动派生”。

9.1 核心概念

@observable：可观察的状态字段。
@computed：根据 observable 计算出的派生值，会被缓存，只有依赖变化时才重新计算。
@action：修改 observable 状态的方法（保证状态变更可追踪）。
Observer：UI 层的观察者 widget，自动订阅其 builder 内用到的所有 observable。

9.2 示例（需要代码生成 `.g.dart`）

part 'counter.g.dart';

class Counter = _Counter with _$Counter;

abstract class _Counter with Store {
  @observable
  int count = 0;

  @computed
  bool get isEven => count % 2 == 0;

  @action
  void increment() => count++;
}

Observer(
  builder: (_) => Text('${counter.count} (even: ${counter.isEven})'),
);

9.3 优缺点

优点：

响应式程度高，Observer 会自动追踪依赖，无需手动指定订阅哪个字段。
@computed 天然支持派生状态缓存，减少重复计算。

缺点：

依赖代码生成（build_runner），项目配置较繁琐。
国内 Flutter 社区中相对小众，学习资料不如 Provider/Riverpod/Bloc 丰富。

10. Redux

flutter_redux 将 Web 前端经典的 Redux 模式移植到 Flutter，核心是单一数据源（Single Source of Truth）+ 纯函数 Reducer。

10.1 核心概念

Store：整个应用唯一的状态容器。
Action：描述状态变化意图的普通对象。
Reducer：纯函数 (State, Action) => State，根据 Action 计算出新状态。
Middleware：拦截 Action，用于处理异步逻辑、日志等副作用。

10.2 示例

// State
class AppState {
  final int count;
  AppState(this.count);
}

// Action
class IncrementAction {}

// Reducer
AppState reducer(AppState state, dynamic action) {
  if (action is IncrementAction) {
    return AppState(state.count + 1);
  }
  return state;
}

// Store
final store = Store<AppState>(reducer, initialState: AppState(0));

StoreProvider<AppState>(
  store: store,
  child: StoreConnector<AppState, int>(
    converter: (store) => store.state.count,
    builder: (context, count) => Text('$count'),
  ),
);

// 触发
StoreProvider.of<AppState>(context).dispatch(IncrementAction());

10.3 优缺点

优点：

状态变化可预测、可追溯（时间旅行调试、状态快照）。
单一 Store，非常适合状态高度集中、需要严格审计变化历史的场景。

缺点：

样板代码多，Dart 生态中已经不如 Bloc/Riverpod 流行，社区活跃度下降。
全局单一 Store 在大型应用中可能变得臃肿，模块化拆分不如 Bloc/Riverpod 自然。

11. 方案对比与选型建议

方案	学习曲线	样板代码量	是否依赖 BuildContext	异步支持	可测试性	典型适用场景
setState	低	极少	是	手动处理	一般	局部/临时状态
InheritedWidget	中	较多（手写）	是	手动处理	一般	框架底层机制，不建议直接裸用
ValueNotifier/ChangeNotifier	低	少	否（对象本身）/是（Builder）	手动处理	好	中小型项目、简单共享状态
Provider	低-中	中	是	手动处理（可配合 FutureProvider）	好	中小型项目、官方推荐入门方案
Riverpod	中-高	中	否	一等支持（AsyncValue）	极好	中大型项目，追求类型安全与可测试性
Bloc/Cubit	中-高	多	是（通过 context.read）	一等支持（Stream）	极好	大型企业级项目，强调架构规范
GetX	低	极少	否	手动处理	一般	快速原型、小团队、追求开发速度
MobX	中	中（含代码生成）	否	手动处理	好	偏好响应式编程范式的团队
Redux	中-高	多	是	需 Middleware	好	需要严格状态审计/时间旅行调试的场景

选型建议

个人项目 / 快速原型：setState + ValueNotifier，或 GetX（开发速度优先）。
中小团队、常规业务 App：Provider 或 Riverpod（Riverpod 是 Provider 的”进化版”，新项目更推荐直接上 Riverpod）。
大型企业级项目、多团队协作：Bloc（架构统一、强制规范、可测试性强）或 Riverpod（类型安全、灵活）。
已有 Web 端 Redux 经验、需要跨端状态逻辑复用：可考虑 Redux，但目前在 Flutter 生态中已非主流首选。

12. 跨状态管理方案的通用原则

无论使用哪种框架，实践中都应当遵循以下原则：

状态提升最小化范围：状态应该放在”刚好能被所有需要它的 widget 共享”的最低公共祖先节点，避免全局滥用。
区分”读”与”订阅”：在事件回调（如 onPressed）中应该”只读一次”（context.read / ref.read），只在 build 方法中才需要”订阅”（context.watch / ref.watch），否则会导致不必要的重建。
精细化订阅，减少无关 rebuild：优先使用 Selector、BlocSelector、ref.select() 等 API，只订阅真正用到的字段，而不是整个状态对象。
业务逻辑与 UI 解耦：状态容器（Model/Bloc/Notifier）中不应该直接依赖 BuildContext 或 Widget，便于单元测试。
善用异步状态的三态模型：无论是 FutureBuilder、Riverpod 的 AsyncValue，还是 Bloc 的 loading/success/failure state，都应该显式处理加载中、成功、失败三种状态，避免边界情况遗漏。
合理使用 key：在列表、动态 widget 场景中，配合状态管理框架正确使用 Key，避免状态错位复用的问题。