购物车数量同时显示在商品列表、详情页和结算页。列表页点一次"加入购物车"，三个地方都要更新；结算页还要等待接口返回最新价格。刚开始用 setState() 很顺手，页面一多，就会遇到一个更实际的问题：这份状态该由谁持有，谁能修改，哪些 Widget 应该跟着重建？
一句话结论：Flutter 状态管理的核心是明确状态的归属、变化路径和观察范围；Provider、Riverpod、Bloc/Cubit、GetX 只是用不同约束回答同一组问题。
这是系列第一章，只比较设计思路和适用场景，不绑定某个包的具体版本，也不把 API 写法当作选型依据。后续章节会固定依赖版本，用同一个购物车例子分别实现和验证。这里的框架特征以各项目公开文档中的核心模型为准，具体 API 和生命周期行为仍需按项目锁定的版本检查。
1. 状态管理究竟在管理什么？
状态是运行中会变化、且变化可能影响界面的数据。购物车数量是状态，接口的加载中、成功、失败也是状态；按钮是否展开同样是状态，但它们不一定要放在同一个地方。
| 状态类型 | 例子 | 通常由谁持有 |
|---|---|---|
| 页面局部状态 | 输入框焦点、展开/收起、当前选中的 Tab | 当前 Widget 或附近的页面层 |
| 跨页面业务状态 | 购物车、登录用户、主题设置 | 页面之外的业务层或明确的共享作用域 |
| 异步数据状态 | 价格请求的加载、结果与错误 | 负责请求与缓存的对象，并让界面订阅它 |
购物车例子的完整路径可以压成一行：
text
点击"加入购物车" → 发出操作 → 状态持有者更新购物车
→ 依赖该状态的 Widget 收到变化 → 重建所需界面图里最关键的不是箭头数量，而是"状态持有者"这个位置。如果三个页面各自维护一个 cartCount，就得额外同步三份副本。框架能帮助传递变化，但不能替你决定哪份数据才是真实来源。服务端价格更是如此：本地展示值可以缓存，最终价格仍要按业务规则从服务端确认。
选框架前，我会先问四个问题：状态由谁创建和销毁？谁有权修改？哪些组件需要观察？异步失败后如何恢复？这四个答案清楚了，后面的框架对比才有意义。
2. 原生能力能走多远？
setState() 是 Flutter 最直接的局部状态更新方式。点一下按钮，修改当前 State 中的值，框架安排相关子树重建。输入框显隐、页面内的选中状态，用它往往最清楚。把这些小状态都搬进全局容器，反而增加了查找和清理成本。
当状态要被几个 Widget 共享时，Flutter SDK 还有 ValueNotifier、ChangeNotifier、InheritedWidget 等基础能力。ChangeNotifier 提供通知监听者的机制，InheritedWidget 能沿 Widget 树向下提供依赖。它们是许多状态管理方案的构件，也可以直接用于范围有限的场景。
麻烦通常出现在规模增长后：跨页面取对象、组织依赖、处理异步加载、测试状态变化、在离开页面时释放资源。此时引入库，是为了给这些问题一套统一约定，而不是因为 setState() 本身"过时"。
3. 四种常见方案，主要差在哪里？
先看整体，不急着比较语法长短。
| 方案 | 核心组织方式 | 擅长的场景 | 需要付出的代价 |
|---|---|---|---|
| Provider | 将对象放进 Widget 树中的作用域，子树按需读取或监听；常与 ChangeNotifier 搭配 |
已有 ChangeNotifier 模型、希望循序渐进改造的项目 |
依赖树和作用域需要设计；跨层读取时要留意使用的 BuildContext。 |
| Riverpod | 用 provider 定义状态及依赖关系，通过 ref 读取、监听和组合 |
依赖关系较多、异步状态较多、希望状态逻辑不绑在 Widget 树读取方式上的项目 | 要理解 provider 的生命周期、失效和依赖重算；团队需要统一写法。 |
| Bloc / Cubit | 将操作转成明确的状态输出；Bloc 通过事件处理，Cubit 通过方法直接触发状态变化 | 状态流转复杂、多人协作、需要清楚追踪"发生了什么" | 事件和状态建模需要更多代码；简单页面也照搬完整流程会显得笨重。 |
| GetX | 以 Controller、响应式值和依赖注册组织状态，也提供路由等能力 | 团队已采用 GetX 整套约定、希望快速统一多类基础能力 | 约定若不严格，依赖入口和对象生命周期会变得隐蔽。 |
这张表有两个容易误读的地方。第一，Provider 不是 ChangeNotifier 的另一个名字 ：它能提供各种对象，ChangeNotifier 只是常见搭配。第二，Bloc 和 Cubit 也不是两个完全不同的架构：它们都输出状态，区别主要在"先发送事件再处理"，还是"调用方法后直接输出"。
Riverpod 与 Provider 名字相近，使用模型却不同。Provider 的常见读取方式依赖 Widget 树中的 BuildContext；Riverpod 把依赖声明成 provider，通过 ref 建立读取和监听关系。GetX 也能让页面很快响应状态变化，但它覆盖路由和依赖注册，选择它意味着团队要同时约定这些能力的边界。
我不会给这四种方案排一个"性能榜"。界面是否流畅，更多取决于订阅范围、数据更新频率、列表构建和实际渲染工作。各方案都能控制重建范围，也都可能因状态放得过大而让太多 Widget 更新；没有相同场景和测量条件，排名没有参考价值。
4. 用购物车例子做一次选型
假设只有商品详情页显示数量，离开页面就不再需要：先用 setState() 或一个局部的 ValueNotifier。把它放到全局，收益很小。
如果列表、详情和结算页都要读同一购物车，且项目已有 ChangeNotifier 模型，Provider 可以用较小的改动提供共享作用域。新项目如果还要组合登录态、购物车接口、优惠规则与异步缓存，我更倾向先评估 Riverpod：依赖关系可以直接成为状态定义的一部分。不过，团队若已经稳定使用 Bloc，迁移成本通常大于这点偏好带来的收益。
当结算流程出现"加入商品、锁定库存、选择优惠券、提交订单、支付回调"等一串需要追踪的业务事件，Bloc 的事件到状态路径会更有价值；不需要单独定义事件的地方，可先看 Cubit。GetX 则适合团队已经把状态、依赖注册和路由都纳入同一套规范的工程。只为一个购物车计数器引入它整套能力，不划算。
无论选谁，结算页的价格请求都要表达加载、成功、失败，并处理重复提交与页面销毁。状态管理框架负责把这些结果送到界面；接口的正确性、库存一致性和支付安全仍由业务与服务端保证。
5. 后续章节怎么展开？
这一章只建立选型坐标。后面会固定同一个购物车需求，逐篇回答更细的问题：
- Provider ：
ChangeNotifier、作用域、读取方式与局部刷新。 - Riverpod：provider 依赖、异步状态、失效和生命周期。
- Bloc/Cubit：事件或方法如何变成状态，如何测试流转。
- GetX：Controller、响应式更新、依赖注册与生命周期。
- 横向实战：同一个功能在不同方案下的代码组织、测试和迁移成本。
先把本文的判断记住就够了：局部状态先留在局部；共享状态明确真实来源；复杂流程让变化路径可追踪。 框架选择应当服务于这三件事，而不是反过来让所有页面迁就框架。