名词
单一数据源：整个应用的状态存储在一个统一的对象树中，而不是分散在各个组件或模块里。
不可变状态：指你不能直接修改状态的值，而是需要创建一个新的值来替换旧的状态。
纯函数：
- 无状态：不依赖外部状态的变化，相同输入总是产生相同输出。
- 无副作用：在执行过程中不影响外部状态，只依赖于输入参数并返回输出结果。
响应式编程：一种基于数据流变化自动传播和响应的编程范式，核心思想是声明式地定义数据之间的关系，当数据变化时，依赖它的逻辑会自动更新（类似 Excel 公式）。
原子化状态：
- Atoms (原子状态)：可被多个组件订阅的最小状态单位，类似于 React 的局部组件状态，但可以在多个组件间共享
- Selectors (选择器)：派生状态，可以从 atoms 或其他 selectors 计算得出
1. Redux
特点：单一数据源、不可变状态、纯函数更新
优点：
- 严格的架构，适合超大型应用（如企业级后台）。
- 强大的中间件生态（如 Redux-Thunk、Redux-Saga）。
- 完备的调试工具（Redux DevTools）。
缺点：
- 模板代码多，开发效率低。
- 学习曲线陡峭（中间件、不可变性处理）。
- 性能问题：全局状态更新可能触发无关组件重渲染。
- 更多的内存占用。由于采用单一数据源，所有状态存储在一个state中，当某些状态不再需要使用时，也不会被垃圾回收释放内存
适用场景：复杂状态逻辑、需要时间旅行调试或严格状态追溯的项目。
2. MobX
特点：响应式编程、自动依赖追踪、可变状态
优点：
- 代码简洁，类似 Vue 的响应式体验。
- 高性能：精确更新依赖变化的组件。
缺点：
- 状态可变性导致调试困难（难以追踪变化来源）。
- 过度灵活易引发代码混乱。
适用场景：中小型应用，追求开发效率且接受可变状态的团队。
3. Recoil
特点：原子化状态、依赖图更新
优点：
- 原生 Hooks 风格，无模板代码。
- 细粒度更新，只依赖特定 atom 或 selector 的组件才会重新渲染。
- 支持并发模式（React 18+）。
缺点：
- 仍处于实验性阶段（Facebook 官方未标记为稳定）。
- 需要为每个状态定义唯一
key。 - 最后一次更新为2023年，在25年1月2号，git仓库已被设置为只读
适用场景：需要细粒度控制渲染的复杂应用（如大型表单、数据看板）。
4. Jotai
特点：Recoil 的极简版、无 Key 设计
优点：
- 比 Recoil 更轻量，无
key和Provider负担。
缺点：
- 社区生态较小。
适用场景：喜欢 Recoil 但希望更简单的项目。
5. Zustand
特点：轻量级 Redux 替代、多 Store 支持
优点：
- 无模板代码，API 极简。
- 更灵活：不需要单一的全局 store，可以创建多个 store
- 更轻量：包体积更小，概念更少
- 支持中间件（持久化、日志等）。
- 性能优异（自动选择依赖更新）。
缺点：
- 缺乏内置计算属性（需手动实现或第三方扩展）。
适用场景：大多数项目（Redux 的平替，平衡简洁与功能）。
6. Hox
特点：基于 Hooks 的轻量级方案
优点：
- API 简单（
createModel+useModel）。 - 无 Provider 嵌套问题。
缺点：
- 调试工具弱，不适合超大型应用。
- 依赖 Hooks
适用场景：中小型应用，快速共享 Hook 状态。
7. Dva
特点：Redux + Redux-Saga + Router 集成
优点：
- 仅有6个API，开箱即用，减少配置成本。
缺点：
- 已停止维护，不推荐新项目使用。
选型建议
| 需求场景 | 推荐库 | 理由 |
|---|---|---|
| 大型复杂应用，强调试需求 | Redux | 严格的架构和工具链支持 |
| 中小型应用，追求开发效率 | Zustand / MobX | 简洁 API，高性能 |
| 需要细粒度渲染控制 | Recoil / Jotai | 原子化状态，精准更新 |
| 快速共享 Hook 状态 | Hox | 无 Provider，极简集成 |
| 新项目，平衡功能与简洁 | Zustand | Redux 的现代替代，生态良好 |
趋势：
- Zustand 逐渐成为 Redux 的替代首选（简化设计 + 良好性能）。
- 原子化状态库（Recoil/Jotai）在复杂交互场景中表现优异。
- Hox 适合 Hooks 优先的小型项目。
