昨天 get 的删库风波之后不管是社区还是我们公司内部的群，基本Ke以说是原地炸了。虽然早上作者解释说是他的 GitHub 账户被风控，但说实话，get 本身积压的问题Yi经够多了。这事儿就像是一根导火索，把大家平时不愿意面对的焦虑一下子全引爆了。

这时候大家问得Zui多的，不再是“这个 API 怎么用”，而是geng扎心的问题：“以后 Flutter 项目状态管理到底该怎么选？”

借着这次机会，我想把 Flutter 生态里主流的状态管理方案，重新摆到桌面上，按真实项目的标准，认认真真聊一遍。不是为了搞什么“清算大会”，而是为了让我们以后睡觉Neng踏实点。毕竟技术选型从来不是一锤子买卖，你今天选一个方案，不只是选它今天写起来爽不爽，你其实是在选未来两三年维护它时的痛苦程度。

生态稳定性：不得不防的“黑天鹅”

这次 get 的事情，对我来说Zui大的提醒，不是“某个包突然不Neng用了”，而是另一件geng本质的事：生态稳定性和治理Neng力，也是技术选型的一部分。

以前大家觉得“Neng跑就行”，这次hen多人才开始意识到：“哦，原来依赖生态稳定，也是技术选型的一部分。”

尤其是早几年，Flutter 生态还没现在这么成熟时GetX 的那种“开箱快、上手爽、什么dou给你带一点”的感觉，对hen多人真的hen有吸引力。你写页面时会感觉：“卧槽，这也太快了吧。” 但这种爽快是有代价的。一旦项目Zuo大，或者维护者本身出问题，这种“大而全”的包就会变成巨大的风险。

所以Ru果你现在问我新项目geng倾向推荐谁，我会先把“生态稳定性”作为第一道筛子。在这个维度上，Provider、Riverpod、Bloc 这种有官方或大社区背书的方案，显然比个人维护的“全家桶”要让人安心得多。

Provider：那个“老实人”的优与劣

Ru果让我给 Provider 起个外号，我会叫它：“老实人方案。”

它Zui大的特点就是：太平衡了。它在学习曲线、功Neng强度和代码侵入性这几个维度上，整体太均衡了。这也是为什么hen多 Flutter 新人第一个真正上手的状态管理，dou是它。

Zui常见的写法其实hen直白：

class UserViewModel extends ChangeNotifier {
  bool loading = false;
  List users = ;
  Future loadUsers async {
    loading = true;
    notifyListeners;
    await Future.delayed);
    users = ;
    loading = false;
    notifyListeners;
  }
}
// 页面里用：
ChangeNotifierProvider(
  create:  => UserViewModel..loadUsers,
  child: Consumer(
    builder:  {
      if  {
        return const CircularProgressIndicator;
      }
      return ListView(
        children: vm.users.map.toList,
      );
    },
  ),
)

你kan，它其实hen好懂。这套东西的优点几乎不用解释：因为它特别符合人脑Zui朴素的思路——我有个数据，我改了它，然后告诉别人“我改了你们kan着办”。

但是Provider Zui大的问题，不是功Neng弱，而是结构约束弱。

它不是不Neng维护，但它特别考验开发者的自觉。Zui开始你只放两个字段，再往后还会加一堆方法。写着写着，一个 ChangeNotifier 就变成了一个“巨型大管家”。Zui后 controller 既像 ViewModel，又像 Service，又像 Router。这对个人项目问题不大，但对团队维护来说是个隐患。

Ru果一个人习惯先堆功Neng，再慢慢补结构，那 Provider 反而不一定让他geng轻松。因为它太自由了自由到你Ke以把任何逻辑dou塞进去。

Riverpod：脑子清楚、结构现代的“中生代主力”

Ru果说 Provider 是“老实人”，那 Riverpod 在我眼里geng像：“脑子清楚、结构现代、Neng打硬仗的中生代主力。”

hen多人会把 Riverpod 理解成“升级版 Provider”。这么说不算全错，但也太粗暴了。Riverpod 不是鼓励你写一个“大而全的状态类”，而是鼓励你把不同职责拆成多个 provider，再组合起来。

我觉得 Riverpod Zui讨喜的一点，是它对异步状态的表达非常自然。Ru果你只拿一个简单异步列表示例去kan Riverpod，其实还没kan到它Zui强的地方。它真正强的是这种场景：比如并发控制、状态依赖。

geng准确一点的说法应该是：异步状态本身就是框架的一等公民。你不需要手动去定义 loading、error、data 三个枚举，而是用 AsyncValue 直接把这些状态表达出来。

final usersProvider =
    AsyncNotifierProvider;
class UsersNotifier extends AsyncNotifier {
  @override
  Future build async {
    await Future.delayed);
    return ;
  }
  Future refreshUsers async {
    state = const AsyncLoading;
    state = await AsyncValue.guard async {
      await Future.delayed);
      return ;
    });
  }
}
// 页面里：
final asyncUsers = ref.watch;
return asyncUsers.when(
  loading:  => const CircularProgressIndicator,
  error:  => Text,
  data:  => ListView(
    children: users.map.toList,
  ),
);

你会发现这里有个hen明显的优势：它hen擅长把依赖关系和状态关系拆清楚。你把它想象成一张依赖图，会geng容易理解。

但这其实是表象。Riverpod geng适合那种愿意先想清楚状态边界，再写代码的人。这hen正常，因为 Riverpod 不是在教你“存一个对象”，而是在教你“组织一组状态节点”。

Ru果团队里成员整体水平还不错，Riverpod 是一个非常舒服的主状态管理方案。它既没有 Bloc Event 那么重，又比 Provider geng容易把结构撑住。Riverpod 的优点是可拆分，但坏处也正是可拆分。Ru果你非要拿一个hen轻的用户列表页，上来就写一堆事件、状态类、派生结构，hen多时候反而是技术过剩。

Bloc 与 Cubit：规矩大的“教官”

hen多人一提到 Bloc，第一反应就是：“太重了。”

这句话不Neng说错，但我觉得它只说了一半。因为hen多人把 Bloc 体系一股脑dou理解成：Event、State、BlocEvent 三件套，写个页面要建三个文件，累得半死。

我其实hen想先替 Cubit 正个名。Cubit geng像是：“有明确状态对象的、工程化一点的 ViewModel。”

class UsersCubit extends Cubit {
  UsersCubit : super);
  Future loadUsers async {
    emit);
    await Future.delayed);
    emit(
      state.copyWith(
        loading: false,
        users: ,
      ),
    );
  }
}

这比hen多项目里“状态逻辑和副作用搅成一锅粥”的写法，要清爽太多。对hen多简单到中等复杂度页面来说Cubit 是非常实用的。它比 Provider geng有“状态层”的味道，又比完整 Bloc Event 版轻hen多。

而 Event 版会逼你把事情说清楚。Bloc 不是单纯地重，它是规矩大。它会逼着你把一些以前Ke以“糊着写”的东西，全部摊开来写清楚。

在 Bloc 生态里你Ke以明确去处理：用 BlocBuilder 渲染 UI，用 BlocListener 处理 Toast、Dialog、路由跳转。这种搭配hen实用。这不是为了多写几个类，而是为了让状态变化路径可追踪。

当业务复杂起来比如一个页面同时有：网络请求、表单验证、本地缓存geng新、UI 动画触发。这时候你再全靠方法名去表达，就会慢慢开始乱。那 Bloc 的价值，真的会越来越明显。

尤其在多人协作里这点特别重要。一眼就Nengkan出：“页面现在到底发生了什么业务动作。”

GetX：让人又爱又恨的“双刃剑”

所以我现在对 GetX 的态度是：我不会建议你们一夜重构。因为说实话，GetX 当年Neng火，不是没原因的。它确实帮hen多 Flutter 开发者解决过实际问题。

它hen擅长把依赖关系和状态关系拆清楚。GetX hen容易让人一路写成这种结构：Zui后 controller 既像 ViewModel，又像 Service，又像 Router。

问题不在它不Neng用，而在它太容易一路“长歪”。hen多写法前期hen丝滑，但越往后越容易出现一种感觉：项目Neng跑，但你说不清它到底靠什么机制在跑。

Ru果这个问题它还Neng帮你解释清楚，那它就值钱。Ru果它让这些东西越来越糊，那它迟早会反噬你。因为业务一复杂，方法驱动就开始不够清楚了。短期开发hen爽，长期kan边界其实hen容易糊。

到底该怎么选？

Zui后我想Zuo的事情hen简单：把选择权还给你自己。状态管理真正要解决的，不是“你用哪个函数刷新页面”，而是下面这几件事：

“状态从哪来为什么变，谁在监听，副作用在哪发生。”

Ru果这个问题它还Neng帮你解释清楚，那它就值钱。Ru果它让这些东西越来越糊，那它迟早会反噬你。

为了不让这篇文章变成“空对空”，我还顺手把同一个业务场景Zuo成了一个开源 Demo，把 Provider / Riverpod / Cubit / Bloc Event 全dou落地了一遍。后面我文中提到的一些对比，不只是嘴上说说基本douNeng在这个仓库里对上代码。

Ru果你们团队现在也在重新评估状态管理路线，希望这篇Neng帮你少踩几个坑。我会这样建议：

1. 简单模块用 Cubit，复杂模块上 Bloc Event。 这套思路，在简单页面里确实显得重。但一旦业务复杂起来它的价值就会越来越大。它既没有 Bloc Event 那么重，又比 Provider geng容易把结构撑住。

2. Ru果团队水平不错，优先考虑 Riverpod。 你会发现，一个状态管理方案，真正的价值，不在于它Neng不Neng写出页面。而是说这次事情把一个以前hen多人不愿意正视的问题，硬生生摊开了：生态稳定性。

3. 谨慎使用 GetX 开启新项目。 因为状态管理迁移这种事，一旦上头，hen容易把“风险治理”Zuo成“二次事故”。注意，我这里不是说 GetX 技术上突然一夜归零了。而是当项目Zuo大之后它还Neng让你回答清楚下面这句话：“状态从哪来为什么变，谁在监听，副作用在哪发生。”

说得再直白一点：你写得好，它hen好用。你写得随便，它也hen容易烂。

Ru果你们团队现在也在重新评估状态管理路线，希望这篇Neng帮你少踩几个坑。Ru果这篇文章让你觉得有点意思，或者帮你理清了一点思路，评论区告诉我，我就继续geng。毕竟在 Flutter 这条路上，谁还没踩过几个坑呢？

---