状态管理需结合项目规模、复杂度、团队经验等因素选择。

Redux、Zustand和 Mobx 是前端领域常见的状态管理库，各自有不同的设计哲学和适用场景。

包名	开发时间	月下载量
Redux	2015
React-Redux	2015
Redux Toolkit	2019
Zustand	2018
Mobx	2015
Mobx React 专用	2015

信息

Redux Toolkit 已经极度降低了 Redux 的使用门槛。Zustand 却因“轻量化”让其快速抢占了 Redux 覆盖不到的场景（如中小型项目、原型开发），同时也吸引了大量“厌烦 Redux 繁琐“的开发者，最终形成了与 Redux 分庭抗礼的局面

一、设计核心理念

• Redux：单一状态树、不可变数据、纯函数更新，强调可预测性和可追溯性。严格数据流和可预测性符合高风险行业对状态管理的演进要求
• Zustand：轻量级“状态容器”，无强制规范，提供灵活的 Hook API，平衡简洁性和灵活性。极简设计（无 Provider、无 action 、 无 reducer ）和优秀性能（精确更新）使其成为中小型项目的新宠
• Mobx：将状态设计成“可观察对象”（Observable），通过自动追踪依赖实现细颗粒度更新 。简洁 API和自动更新机制能快速提升中小型项目的开发效率

二、状态更新方式

• Redux：必须通过 dispatch(action) 触发 Redux 函数，返回新的不可变状态
• Zustand：通过类似 useState 的 Hook 直接修改状态，或使用自定义 Setter 函数（支持不可变/直接修改）
• Mobx：直接修改 可观察状态 （通过 observable 或 makeObservable 定义），直接触发依赖组件的重新渲染

三、 学习曲线

• Redux：高，需要理解 Action、Reducer、Store、Middleware 等概念。但是，概念清晰，逻辑严谨，调试工具强大，时间旅行调试出色
• Zustand：低，API 极简，类似 React Hooks ，无强制规范。对于非常复杂的应用，缺乏像 Redux 那样的严格的结构约束，可能导致
• Mobx：中，需理解可观察对象、计算属性、反应（Reaction）等概念。但响应式的“魔法”有时会让新手难以理解其内部原理（例如，为什么某个组件没有重新渲染？）。过度使用和不当使用可能会导致性能问题和难以追踪的副作用。学习如何正确使用装饰器或 makeObservable 也需要一定时间。API 本身并不复杂，但理解其响应式系统的工作原理是关键

四、 样板代码量

• Redux：高，需要编写 Reducer、Action Creator，早期依赖 React-Redux 的 connect 或 useSelector
• Zustand：极低，仅需定义 create 函数，无额外模版代码
• Mobx：低，通过装饰器或 makeObservable 简化状态定义，组件中使用 observer 包裹即可

五、性能优化

• Redux：依赖手动优化（如 React-Redux 的 useSelector 浅比较，或中间件如 redux-batched-actions）。若为正确使用 useSelector ，可能导致不必要的组件重渲染
• Zustand：自动优化，通过 shallow 比较或自定义相等性检查，避免不必要的重渲染。默认行为类似 useState ，可通过 shallow 或自定义函数控制更新粒度
• Mobx：自动追踪依赖（通过 observer 组件仅订阅相关状态），细粒度更新。无需手动优化，状态变化时仅重渲染依赖该状态的组件

六、 生态

• Redux：最成熟，中间件如 redux-thunk、redux-saga、Redux Toolkit，工具如 redux-devtools（各浏览器插件）
• Zustand：快速增长，中间件如 presist、devtools，支持 Redux-like 中间件模式。支持自定义中间件（如日志、持久化），可扩展为类 Redux 结构
• Mobx：较丰富，支持装饰器、函数式 API，可与其他库（如 mobx-persist）集成

🗃️ redux

5 个项目

🗃️ Zustand

1 个项目

🗃️ Mobx

2 个项目