状态管理方案对比

Flutter 中有多种状态管理方案，选择合适的方案很重要。

方案总览

方案	难度	适用场景	官方推荐
setState	⭐	组件内部简单状态	是
InheritedWidget	⭐⭐	自定义状态共享	是（基础）
Provider	⭐⭐	中小型项目状态共享	是
Riverpod	⭐⭐⭐	Provider 的改进版	社区推荐
Bloc / Cubit	⭐⭐⭐	大型项目、复杂业务逻辑	社区推荐
GetX	⭐	快速开发，功能多	社区

选择指南

项目规模 / 复杂度
│
├── 小型 Demo / 学习阶段
│   └── setState
│
├── 中型项目（几个页面共享状态）
│   └── Provider
│
├── 大型项目（复杂状态逻辑）
│   └── Riverpod 或 Bloc
│
└── 追求开发速度
    └── GetX（但要注意维护风险）

各方案特点

setState

优点	缺点
简单直接	无法跨组件共享
无需额外依赖	层层回调麻烦
Flutter 内置	不适合复杂场景

Provider

优点	缺点
官方推荐	需要理解 BuildContext
轻量易学	大型项目不够强
依赖注入方便	watch/read 容易混淆
社区活跃

Riverpod

优点	缺点
Provider 的改进版	学习曲线稍高
编译时安全	API 变化较多
不依赖 BuildContext	生态还在发展
更好的测试支持

Bloc / Cubit

优点	缺点
严格的架构模式	样板代码多
适合团队协作	学习成本高
事件驱动，逻辑清晰	简单场景显得繁琐
好的测试能力

GetX

优点	缺点
开发速度快	不够规范
功能全面（路由、状态、DI）	长期维护不确定
学习成本低	过于「魔法」
样板代码极少	与 Flutter 设计理念不一致

详细用法请参考 GetX 教程。

推荐学习路线

1. 入门：先用 setState 理解状态管理基本概念
2. 进阶：学习 Provider，解决跨组件状态共享
3. 深入：根据项目需求选择 Riverpod 或 Bloc
4. 快捷：追求开发速度时，可了解 GetX

TIP

不要过度设计。如果 setState 能解决问题，就不要引入 Provider。如果 Provider 够用，就不需要 Riverpod。