Flutter 状态管理框架很多，风格差异比较大，如果你是 Android 开发背景（尤其有 Redux / MVVM 经验），会更容易找到熟悉的模式。
1. 核心对比表
| 框架 / 模式 | 学习成本 | 代码复杂度 | 性能 | 社区活跃度 | 特点 | 适用场景 |
|---|---|---|---|---|---|---|
setState（原生） |
★ | 低 | 高 | Flutter 自带 | 最简单直接，局部刷新 | 小项目、Demo、状态简单 |
| InheritedWidget / InheritedModel | ★★ | 中 | 高 | 官方支持 | Flutter 底层依赖，能实现跨组件状态共享 | 自定义轻量状态管理 |
| Provider | ★★ | 中 | 高 | 官方推荐，社区大 | 基于 InheritedWidget 封装，简洁、可组合 | 中小型项目，或初学 |
| Riverpod | ★★★ | 中偏低 | 高 | 社区活跃 | Provider 升级版，无 Context 依赖，支持热重载 | 中大型项目、复杂依赖 |
| Bloc / Cubit | ★★★ | 中偏高 | 高 | Google 官方维护，社区大 | 强约束，状态单向流，事件驱动 | 大型团队、多人协作 |
| GetX | ★ | 低 | 高 | 社区大 | 语法短、集成路由/依赖注入/国际化 | 快速开发、小团队 |
| MobX | ★★★ | 中 | 高 | 社区稳定 | 响应式，数据变化自动刷新 UI | 数据驱动、多状态依赖 |
| Redux | ★★★★ | 高 | 高 | 社区老牌 | 严格单向数据流，可追踪历史 | 超大型项目、跨端共享逻辑 |
| Signals | ★★ | 低 | 高 | 新兴 | Flutter 官方实验性响应式 API，无需三方依赖，API 类似 Vue/SolidJS | 未来主流候选、简单响应式场景 |
2. 框架特点详解
1）setState
- 优点：无依赖、快速上手
- 缺点：状态分散、难维护，跨页面状态传递复杂
- 适合：状态很简单，或只是局部刷新的场景
2）InheritedWidget / InheritedModel
- 优点：无三方依赖，Flutter 原生方案
- 缺点：手写模板较多，不够直观
- 适合：想自己封装轻量状态管理
3）Provider
- 优点：官方推荐，API 简洁，容易组合
- 缺点：依赖 Context，可能导致嵌套
- 适合：中小型项目，入门状态管理
4）Riverpod
- 优点：无 Context 依赖，可在任意位置读写，支持热重载、代码生成
- 缺点：心智成本稍高
- 适合：中大型项目，需要良好可测试性
5）Bloc / Cubit
- 优点：强制单向数据流，分离业务与 UI，调试方便（Bloc Observer）
- 缺点：样板代码多，上手成本高
- 适合：大型团队，多人协作
6）GetX
- 优点：API 极简，几乎零样板代码；集成路由、DI、国际化
- 缺点：黑魔法多，生命周期管理需谨慎
- 适合：小团队、快速迭代项目
7）MobX
- 优点：响应式编程体验好，数据变化自动触发 UI
- 缺点：需要代码生成，调试难度稍高
- 适合：数据依赖复杂的应用
8）Redux
- 优点：可追踪状态历史，调试和回溯非常方便
- 缺点：样板代码极多，过于重量级
- 适合：超大型项目，或需要与 React / RN 共享业务逻辑
9) Signals
- 优点：
- Flutter 官方推出（未来可能稳定）
- 无三方依赖
- 简单直观，类似 Vue ref 或 SolidJS 的 signal
- 自动监听依赖变化
- 缺点：
- 目前还处于实验阶段
- 生态文档较少
- 适合：
想用官方方案的响应式管理
不想引入三方依赖的小项目/中型项目
3. 选型建议
- 小项目 / Demo：
setState/GetX - 中小型项目：
Provider/Riverpod - 大型项目：
Bloc/Riverpod - 多人协作、严格架构：
Bloc/Redux - 数据依赖复杂：
MobX/Riverpod - 快速 MVP 开发：
GetX
4. Flutter 状态管理选型流程图
