前言
如果你写 Flutter 写到一定阶段，迟早会遇到一个问题：
项目一开始很简单，用
setState就够了 过一阵子开始加 Provider 再后来又有人提 Riverpod / Bloc 最后大家都在问：我们到底该用哪个？
如果你有前端或者 RN 经验，这一幕其实一点都不陌生。
Redux、MobX、Zustand、Recoil…… 前端早就经历过一次完整的'状态管理百家争鸣'。
那问题来了：
为什么 Flutter 这么快就走上了和前端一模一样的路？
状态为什么会'爆炸'？不是 Flutter 的锅
先说一个很多人不太愿意承认的事实：
状态复杂化，几乎是所有中大型应用的必经之路。
状态从什么时候开始失控？
你回忆一下项目的演进路径，通常是这样的：
- 一开始：
页面里几个变量，
setState很香 - 业务变复杂： 表单、列表、筛选条件、分页状态开始增多
- 再后来： 登录态、用户信息、权限、配置、缓存
- 最后： 多页面共享状态 + 异步 + 回退恢复
这时候你会发现一个很现实的问题：
状态已经不再属于'某一个 Widget / 页面'了。
而一旦状态开始跨页面、跨模块存在，单纯的 setState 就一定会崩。
Flutter 和前端，状态模型几乎是同构的
这也是为什么 Flutter 会自然长出一堆状态管理方案。
因为 Flutter 和 React 本质上解决的是同一个问题：
UI = f(State)
状态一变，就要重新描述 UI。
对比一下两边的状态形态
前端 / RN
- 组件本地状态
- 页面级状态
- 全局状态（用户、配置、权限）
Flutter
- Widget 内部 State
- 页面级 State（ViewModel / Controller）
- 全局 State（Provider / Riverpod）
你会发现，层级是一模一样的，只是名字不同。
一个 Flutter 中最典型的'状态开始失控'的例子
先看一个非常常见的写法。
初期写法：状态直接写在页面里
class UserPage extends StatefulWidget {
@override
State<UserPage> createState() => _UserPageState();
}
class _UserPageState extends State<UserPage> {
bool loading = false;
String userName = '';
Future<void> loadUser() async {
setState(() {
loading = true;
});
await Future.delayed(Duration(seconds: 1));
setState(() {
userName = 'Tom';
loading = false;
});
}
@override
void initState() {
super.initState();
loadUser();
}
@override
Widget build(BuildContext context) {
return loading
? CircularProgressIndicator()
: Text('Hello $userName');
}
}
一开始看起来没毛病。
但问题很快就会出现：
- 用户信息被多个页面用
- 页面返回时状态要保留
- 刷新、错误、空态开始增多
你会发现：
页面既负责 UI，又负责业务状态，又负责异步流程。
这一步，就是 Flutter 和前端一起迈进'状态复杂区'的开始。
Provider / Riverpod / Bloc，其实是在解决同一件事
很多 Flutter 新手会纠结：
Provider 和 Riverpod 到底差在哪？ Bloc 是不是太重了？
但从设计目标来看，它们高度一致：
把状态从 Widget 中'拎出来'
一个最基础的 Provider Demo
class CounterModel extends ChangeNotifier {
int count = 0;
void increment() {
count++;
notifyListeners();
}
}
void main() {
runApp(
ChangeNotifierProvider(
create: (_) => CounterModel(),
child: MyApp(),
),
);
}
class CounterView extends StatelessWidget {
@override
Widget build(BuildContext context) {
final counter = context.watch<CounterModel>();
return Column(
children: [
Text('Count: ${counter.count}'),
ElevatedButton(
onPressed: counter.increment,
child: Text('Add'),
),
],
);
}
}
这和 Redux / Zustand 有什么区别？
如果你把语言换一下：
- ChangeNotifier ≈ Store
- notifyListeners ≈ dispatch
- watch ≈ subscribe
逻辑结构几乎完全一致。
Flutter 并不是'模仿前端'， 而是在声明式 UI 体系下，状态管理只有这一条路能走。
RN 项目为什么会掉进 Redux 地狱？
这件事对 Flutter 其实是一个非常重要的警示。
Redux 出问题，从来不是因为它'设计不好'，而是因为：
- 所有状态都被塞进全局 Store
- 页面级、组件级状态没有边界
- 一点小交互也要走 action → reducer
结果就是：
状态集中化过度，反而失去可维护性。
Flutter 如果无脑全局 Provider / Riverpod，结局是一模一样的。
iOS 状态为什么看起来更'稳定'？
很多 iOS 开发者会说：
我写 UIKit / MVVM，很少纠结状态管理。
这是因为 iOS 用的是另一套代价体系。
iOS 的'稳定'，来自强约束
- 页面生命周期固定
- Controller 持有 View
- 数据流向非常明确
你要更新什么，就直接调方法。
viewModel.userName = "Tom"
view.update()
不会有'自动重建整棵 UI 树'这件事。
但代价是什么？
- 状态复用成本高
- 跨页面共享复杂
- 多端复用几乎不可能
iOS 的稳定，是用灵活性和扩展性换来的。
真正通用的，是'状态分层'，而不是具体框架
如果你横向看 Flutter / 前端 / iOS，会发现一个共识：
状态不是越集中越好，而是各归其位。
一个跨技术栈通用的状态分层模型
本地 UI 状态
- loading
- checkbox 勾选
- 动画开关
放在 Widget / Component 内部
页面业务状态
- 列表数据
- 表单内容
- 页面筛选条件
放在 ViewModel / Controller / Notifier
全局状态
- 登录态
- 用户信息
- 配置、权限
少而精，慎重放全局
用 Flutter 再写一版'分层正确'的 Demo
class UserState extends ChangeNotifier {
String userName = '';
bool loading = false;
Future<void> loadUser() async {
loading = true;
notifyListeners();
await Future.delayed(Duration(seconds: 1));
userName = 'Tom';
loading = false;
notifyListeners();
}
}
class UserPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
final state = context.watch<UserState>();
if (state.loading) {
return CircularProgressIndicator();
}
return Text('Hello ${state.userName}');
}
}
- UI 只关心展示
- 状态逻辑集中
- 页面结构清晰
这套结构，在 React、Flutter、甚至 SwiftUI 中都成立。
总结
Flutter 走向'状态管理百家争鸣'，不是偶然，而是必然：
- 声明式 UI → 状态成为核心资产
- 项目变大 → 状态必然外提
- 外提之后 → 就一定会有流派之争
