一、状态管理概述：为什么需要状态管理

说实话，我刚入行那会儿，对状态管理这件事是有点抵触的。

你想啊，一个简单的页面，几个组件互相传传数据，用 props 就能搞定，干嘛要引入那么重的库？直到我接手了一个真正的「大型项目」——一个拥有 200+ 组件的后台管理系统。嗯，那感觉就像在玩俄罗斯方块，数据在组件间飞来飞去，你根本不知道哪个方块会卡住。

为什么需要状态管理？三个核心痛点

我总结下来，状态管理要解决的无非是三个问题：

  • 数据共享：多个组件需要读取同一份数据。比如用户登录信息，几乎每个页面都要用。用 props 一层层传？那叫「props drilling」，传着传着你就疯了。
  • 数据一致性：A 组件改了数据，B 组件必须立刻知道。没有统一的状态管理，你只能靠事件总线或者全局变量，那简直是给自己埋雷。
  • 可预测性：数据是怎么变的？什么时候变的？谁让它变的？没有清晰的变更流程，调试就像在迷雾里找路。

核心观点：状态管理的本质，不是「管理数据」，而是「管理数据的变化」。数据本身是静态的，变化才是动态的、需要被追踪的。

我在项目中遇到过最惨的一次：一个电商后台的购物车模块，三个开发各自维护自己的状态。结果用户加了一个商品，页面显示数量是 3，结算时却变成了 2。查了两天才发现，是某个组件在渲染时偷偷重置了状态。从那以后，我坚决要求团队统一状态管理方案。

React 状态管理发展史

React 的状态管理，说白了就是一部「从混乱到有序」的进化史。我把它分成四个阶段，你感受一下：

第一阶段：石器时代（React 早期）

那时候只有 this.state 和 this.setState。组件之间通信？全靠父组件传 props。跨层级通信？用回调函数一层层往上冒泡。我记得当时有个同事写了个 7 层嵌套的回调，代码看起来就像洋葱，一层剥开还有一层。

第二阶段：Redux 时代（2015-2019）

Dan Abramov 搞出了 Redux，一下子成了行业标准。单向数据流、纯函数 reducer、不可变数据——这些概念让状态管理变得「可预测」了。但说实话，Redux 的样板代码是真的多。一个简单的计数器，你得写 action type、action creator、reducer、connect... 我团队里有个新人，光看这些代码就看了两天。

第三阶段：百花齐放（2019-2022）

MobX 用响应式编程的思路杀了出来，Zustand 以极简 API 俘获人心，Recoil 带着 Facebook 的光环登场。这个阶段的特点是：大家都在试图解决 Redux 的痛点——样板代码多、学习曲线陡、性能优化难。

第四阶段：现代方案（2022 至今）

现在的主流方案已经趋于成熟。Zustand 成了很多新项目的首选，Redux Toolkit 大幅降低了 Redux 的使用门槛，Recoil 在 Facebook 内部用得不错但社区热度一般。我个人习惯是：小项目用 Zustand，大项目用 Redux Toolkit，特殊场景考虑 MobX。

常见方案对比

下面这张表，是我根据自己的实战经验整理的。你直接拿去用，面试、选型都够用。

方案 核心思想 学习曲线 样板代码 性能 适用场景
Redux 单向数据流 + 纯函数 陡峭 多 中等（需手动优化） 大型项目、多人协作
MobX 响应式 + 可变数据 中等 少 好（自动追踪依赖） 中小型项目、表单密集型
Zustand 极简 + hooks 低 极少 好（按需订阅） 中小型项目、快速原型
Recoil 原子化 + 派生状态 中等 少 好（细粒度更新） 复杂数据依赖场景

Redux：老大哥，稳但重

Redux 的优点很明显：社区生态最丰富，中间件体系完善，调试工具强大。但缺点也很突出——样板代码多。你写一个 action，要定义 type、创建 action creator、写 reducer、再 connect 到组件。我曾经统计过，一个中等复杂度的 CRUD 页面，Redux 的样板代码占了总代码量的 40%。

我的建议：如果你用 Redux，一定要用 Redux Toolkit。它内置了 createSlice、createAsyncThunk，能把样板代码减少 70% 以上。我现在的 Redux 项目，基本不写手动的 action type 和 reducer。

MobX：响应式，爽但容易失控

MobX 的思路是「你只管改数据，我帮你更新视图」。用起来确实爽，尤其是表单场景。但问题在于：可变数据太自由了，你可以在任何地方修改 store，调试时根本不知道数据是在哪里被改的。我曾经在一个 MobX 项目里，花了三天时间追一个 bug，最后发现是某个 setTimeout 里直接改了 observable 对象。

避坑指南：我曾经因为 MobX 的「自由」吃过亏。建议团队约定：所有数据修改必须通过 action 方法，禁止直接修改 observable 属性。否则，调试就是噩梦。

Zustand：小而美，新项目的首选

Zustand 的 API 简单到令人发指：一个 create 函数，返回一个 hook。没有 Provider，没有 reducer，没有 action type。你想想看，一个状态管理库，核心代码只有 1KB，却能解决 80% 的状态管理问题。我最近两个新项目都用的 Zustand，开发效率至少提升了 30%。

// Zustand 示例：一个计数器
import { create } from 'zustand'

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

// 在组件中使用
function Counter() {
  const { count, increment } = useStore()
  return <button onClick={increment}>{count}</button>
}

看到没？就这么几行代码，一个完整的状态管理方案就出来了。没有 Provider 包裹，没有 connect 高阶组件，就是一个 hook。

Recoil：Facebook 出品，但有点「学院派」

Recoil 的核心概念是 atom（原子）和 selector（选择器）。atom 是最小状态单元，selector 是派生状态。它的优势在于：可以精确控制每个组件订阅哪些状态，从而实现细粒度的性能优化。但问题是，Recoil 的 API 设计偏学术，学习曲线不低。而且社区生态远不如 Redux 和 Zustand。

我的判断：Recoil 适合那些状态依赖关系特别复杂的场景，比如数据可视化、实时协作编辑。普通业务项目，用 Zustand 或 Redux Toolkit 就够了，别给自己找麻烦。

如何选择？我的实战建议

说了这么多，到底怎么选？我给出一个简单的决策树：

  • 项目规模小（10 个组件以内）：用 React 自带的 useState + useContext 就够了。别引入任何状态管理库。
  • 中等规模（10-50 个组件）：首选 Zustand。简单、高效、够用。
  • 大型项目（50+ 组件，多人协作）：Redux Toolkit。生态成熟，规范性强，适合团队协作。
  • 特殊场景（表单密集、实时数据）：考虑 MobX。响应式编程在表单场景下确实好用。
  • 复杂依赖（数据可视化、编辑器）：可以试试 Recoil。但要做好学习成本的心理准备。

嗯，这就是我对状态管理的一个整体认知。说白了，没有银弹，只有最适合你当前项目的方案。下一章，我会带你深入 Zustand，看看它到底是怎么做到「小而美」的。

← 上一章 📖 返回目录 下一章 →