5.3 常用状态管理方案对比

5.3 常用状态管理方案对比

本节摘要：当状态复杂到组件内部装不下时，需要全局状态管理方案。RN 侧是 Redux、MobX、Zustand，Flutter 侧是 Provider、Riverpod、Bloc。本节不吹不黑，讲清每个方案的核心思想、优缺点与适用场景，并给出按项目规模与团队习惯选型的方法。核心判断：方案之争多是规模之争。

本节目标

阅读完本节，你应当能够：

1. 说出 Redux 的单一 Store 与纯函数 Reducer 思想。
2. 对比 Redux、MobX、Zustand 三者的哲学差异。
3. 理解 Provider、Riverpod、Bloc 的定位与取舍。
4. 按项目规模与团队情况做出合理选型。

一、问题与直觉

状态管理方案多如牛毛，每个社区都有自己的拥护者，网上争论不休。新手最容易被绕晕。但退一步看，这些方案回答的是同一个问题：当"状态放组件里"不够用时，怎么组织全局状态。

一个反直觉的判断先放在这里：方案之争，多数是规模之争。小项目用最简单的方案反而最高效，大项目才需要更严格的约束。把项目规模放第一位去选型，很多纠结自然消失。本节先讲清各方案"主张什么、付出什么"，再给选型方法——不站队，只看适配。

还要提醒一点：这些方案不是"非此即彼"的排他选择。同一个项目里，Redux 管全局复杂状态、Zustand 管局部便捷状态、Context 管主题这类低频数据，是完全常见的组合。选型不是"选一个用到死"，而是"为每种状态选最合适的工具"。带着这个认识，你读下面的方案介绍时会更加从容——它们不是竞争对手，是工具架上的不同工具。

二、核心原理

2.1 RN 三巨头：Redux、MobX、Zustand

Redux 主张"严格可预测"。核心是单一 Store（全部状态放一个对象树）、状态只读（唯一改变方式是派发 Action）、纯函数 Reducer（接收状态与 Action 返回新状态）、单向数据流。

Redux 的优点是可预测、易测试（Reducer 是纯函数）、生态强大（中间件处理异步）；缺点是样板代码多、概念多、学习曲线陡。

Redux 的样板代码到底长什么样。说 Redux 样板多不是抽象抱怨，看一段就知道。定义一个计数器状态，需要写 Action 类型常量、Action 创建函数、Reducer 函数，再配置 Store，最后在组件里连接。全套代码比 useState 多出十几倍。这带来一个思考：约束与样板是 Redux 的"购买可预测性"的成本。大项目里这份成本换来的是清晰的全局数据流；小项目里这份成本就是纯负担。理解"成本换收益"的结构，比记住 Redux 的 API 更重要。

MobX 主张"响应式、少样板"。用可观察状态（Observable）加自动追踪：状态变了，依赖它的组件自动更新。优点是代码量少、接近面向对象思维、性能好（细粒度追踪）；缺点是约束弱、状态变化追踪不如 Redux 清晰。

Zustand 主张"极简"。基于 Hooks，创建一个 Store 只需一个函数，几乎没有样板代码，且不需要 Provider 包裹。优点是极简、性能好、学习成本低。它像是"Redux 的约束与 MobX 的简洁之间取了个平衡点"。

Zustand 的形态值得细看，因为它是"极简"的范本：

import { create } from 'zustand';

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

// 组件里直接读取与修改
function Counter() {
  const count = useStore((state) => state.count);
  const increment = useStore((state) => state.increment);
  return <Button title="加一" onPress={increment} />;
}
​

一个函数建 Store、一个 Hook 读数据、一个方法改数据——没有 Provider、没有 Action、没有 Reducer。这就是 Zustand 的"极简"：把 Redux 的严格约束去掉，保留"状态集中、更新可控"的内核。

2.2 Flutter 三巨头：Provider、Riverpod、Bloc

Provider 是 Google 官方推荐的方案，基于 InheritedWidget 封装。代码量少、与 Flutter 契合度高，适合中小型项目。上一节你已经理解了它的底层原理，所以 Provider 对你而言只剩"怎么用"的问题。

Riverpod 是 Provider 作者的改进版。解决了 Provider 的编译时安全问题（依赖错配在编译期暴露），更灵活，适合需要更强类型安全与测试性的项目。

Bloc 主张"事件驱动的严格模式"。状态变化通过事件流（Stream）驱动，逻辑与 UI 分离彻底。适合大型复杂应用与需要团队强约束的场景，但样板代码偏多、学习曲线陡。

2.3 双框架方案的对应关系

RN 与 Flutter 的方案可以建立对应：Redux 对应 Bloc（都主张严格、可预测、样板多），Zustand 对应 Provider（都主张极简、好用），MobX 与 Riverpod 则在"响应式与安全"之间各有侧重。理解这个对应，选型时可以把两边的经验互相迁移。

2.4 一个常被忽略的维度：团队约束

选型时还有一个常被忽略的维度：团队需要什么样的约束。这不是技术问题，是组织问题。

小团队或一个人开发，约束越少越高效——Zustand 或 Provider 的自由度让你快速迭代；大团队多人协作，约束反而保护质量——Redux 或 Bloc 的严格结构让每个人写的状态代码风格一致，review 成本低。这解释了为什么很多大厂内部强制用 Redux 或 Bloc：不是因为它"最好"，而是因为它让"队伍整齐"。

考虑团队约束时，还可以问一句"新人上手要多久"。严格方案的文档和范式更规范，新人学的是"标准答案"；灵活方案靠的是团队自律，新人容易写出风格迥异的代码。选型时把"团队组成与流动"放进考量，往往比技术对比更能决定成败。

三、工程实践要点

3.1 方案全景对比

这张图的结论一句话：规模决定方案，约束决定选择。先看项目多大，再看团队要不要强约束，选型就有了方向。

3.2 各方案速查

3.3 选型决策的三个问题

问题一：项目多大？ 小项目直接 Zustand（RN）或 Provider（Flutter），别为未来过度设计。

问题二：团队需要强约束吗？ 需要（多人协作、长期维护）选 Redux 或 Bloc，靠框架约束统一写法。

问题三：测试与类型安全重要吗？ 重要就考虑 Riverpod 或 Redux 工具链，它们为测试设计。

⚠️ 常见坑：因为"Redux 最流行"或"Bloc 最正规"就选它们，不考虑项目规模。重型方案在小项目里是负担不是资产。选型的唯一标准是"适不适合"，不是"热不热门"。
💡 关键直觉：状态管理方案的复杂度应该匹配项目复杂度。项目长不大，方案就别升级——过度设计比方案选错更常见，也更浪费。

3.4 一个务实建议

如果你是初学者，我的建议很直接：RN 先掌握 Zustand，Flutter 先掌握 Provider。两个都是"上手快、够用、不背锅"的方案，能覆盖绝大多数项目的需求。等真正遇到"Zustand 或 Provider 不够用"的场景（多模块大型应用、团队强协作），再学 Redux 或 Bloc 也不迟——那时候你有项目经验打底，理解这些重型方案会快得多。

FAQ：状态管理选型的常见疑问

问：状态管理库是不是必须用？能不能只用组件状态加 Context？ 完全可以。中小项目用 setState 或 useState 加 Context 就能撑起来，很多上线的应用就是这么写的。状态库解决的是"状态复杂到难以维护"的问题，不是所有项目的标配。先用内建机制，遇到痛点再引入库，是最务实的路径。

问：Redux 是不是过时了？ 没有。它仍是大型 React 项目的主流选择之一，Redux Toolkit 大幅简化了样板代码。它确实不如新方案"时髦"，但"严格可预测"的价值在大型复杂项目里始终存在。选不选它，看项目规模与团队，别被"过时论"带偏。

问：同时学两套框架的状态管理，会不会记混？ 会混乱一阵，但这是因为"方案名字"太多，而不是"概念"太多。抓住对应关系就稳了：RN 的 useState 对 Flutter 的 setState，RN 的 Context 对 Flutter 的 InheritedWidget，RN 的 Zustand 对 Flutter 的 Provider。记概念对应，不记孤立名字，混乱自然减少。

问：项目中途能不能换状态管理方案？ 能，但成本不低。规模小的项目换起来轻松（状态本来就少）；大型项目换方案涉及大量重构。所以选型前置思考很重要——早期多花半小时评估，胜过后期三周重构。

3.5 方案迁移的一个提醒

如果你在 RN 与 Flutter 之间切换使用不同状态库，请记住：别强行把一种方案的写法套到另一种。Redux 的 action 命名习惯搬到 Flutter 的 Provider 里会显得别扭，Bloc 的事件流搬到 RN 里也未必合适。迁移时迁移的是"状态归属的判断逻辑"（数据该放哪、谁更新），而不是"具体 API 的写法"。每种库都按它的惯用法写，代码才自然、团队才读得懂。这也是本章反复强调"理解核心主张"而不是"背诵 API"的原因。

3.6 学习路径建议与时间投入

面对多种状态库，最忌"每个都浅尝辄止"。建议的学习路径是：把推荐的方案（RN 的 Zustand、Flutter 的 Provider）完整学会并用于真实项目，其他方案达到"能看懂、能评估"的程度即可。判断理解程度有个标准：能说出某个方案与推荐方案的三个差异点（比如样板量、约束强度、性能机制），而不是"听说过名字"。这样既不被方案数量淹没，又保持了横向对比的能力。等真实项目遇到瓶颈，再针对性深入第二方案，效率远高于一开始就全学。

3.7 本节知识的验收标准

学完本节，拿三个问题自检：第一，能不用查资料说出 Redux 的核心三件套（Store、Action、Reducer）与它们的关系吗？第二，能说出 Zustand 与 Redux 的至少两个差异吗？第三，面对一个具体的项目规模，能给出选型理由而不是"大家都用"吗？三个问题都答得上，本节才算过。选型能力不是背方案，而是"用方案回答具体问题"的能力——这正是工程经验与知识积累的分水岭。

温故知新

• RN 三方案：Redux 严格可预测、MobX 响应式少样板、Zustand 极简。
• Flutter 三方案：Provider 官方推荐、Riverpod 类型安全、Bloc 严格事件驱动。
• 双框架对应：Redux 对 Bloc、Zustand 对 Provider，经验可互相迁移。
• 规模决定方案：小项目用轻方案，大项目才需要强约束。
• 选型三问：项目多大、团队要不要约束、测试安全重要吗。
• 过度设计之害：重型方案在小项目是负担，别为热度选型。
• 务实起点：RN 先 Zustand、Flutter 先 Provider，够用且不背锅。

方案对比结束，下一节讲状态管理的时间维度——生命周期与副作用，让状态在正确的时机被初始化、被清理。