跳转到内容
IO IO IO

状态库对比

这页不是“谁更强”的结论页，而是“当前项目该怎么选”的决策页。

三步决策流程

Section titled “三步决策流程”

第一步：判断你的主要痛点

Section titled “第一步：判断你的主要痛点”
  • 如果痛点是“流程规范、审计、团队强约束”：先看 Redux。
  • 如果痛点是“React 内快速落地、心智轻”：先看 Zustand/Jotai。
  • 如果痛点是“深层状态更新、回放排障、跨框架复用”：优先评估 IO。

第二步：判断状态形态

Section titled “第二步：判断状态形态”
  • 以原子拆分为主，且团队能长期维护 atom 图：Jotai/Recoil 更直观。
  • 以树结构业务对象为主，且嵌套更新频繁：IO 更贴合。
  • 以 OOP 领域建模为主：MobX 可能更顺手。

第三步：判断运行时边界

Section titled “第三步：判断运行时边界”
  • 只在 React 内使用：所有候选都可。
  • 需要跨 React/Vue/Svelte 或无框架复用：IO 优势明显。
  • 需要内建 patch 级追踪与回放：IO 更直接。

快速对比矩阵

Section titled “快速对比矩阵”
维度IOReduxZustandMobXJotaiValtio
状态组织树路径 + Unitreducer/actionstore + selectorobservable 对象atom 图proxy 对象
深层更新直接路径写入通常需要 reducer 样板依赖 set 封装写法自然依赖 atom 设计写法自然
订阅粒度路径级（细）通常 selector通常 selector使用追踪（细）atom 级（细）使用路径
更新追踪patch/update 一等能力action 日志依赖中间件约定依赖工具依赖工具以快照为主
跨框架复用强中（多为 React）弱（偏 React）中弱（偏 React）弱（偏 React）

IO 最适配的场景

Section titled “IO 最适配的场景”
  • 业务状态是深层树结构，且字段更新频繁。
  • 你希望“路径即边界”，组件只订阅真正变化的字段。
  • 你需要更新日志用于回放、撤销、审计或故障定位。
  • 你计划把同一状态模型复用到多个框架。

不建议优先选择 IO 的场景

Section titled “不建议优先选择 IO 的场景”
  • 项目只需非常轻量的 React 局部状态，且深层更新很少。
  • 团队已经高度标准化在 Redux 流程治理上，迁移收益有限。
  • 项目完全以 atom 图为核心设计，且维护成本可控。

迁移落地建议

Section titled “迁移落地建议”
  1. 先迁移一个业务切片，不做全局替换。
  2. 先替换读取订阅，再替换写入动作。
  3. 多字段写入统一 commit，高频路径统一 batch/schedule。
  4. 用更新日志做回归验证，再扩大迁移范围。

常见误区

Section titled “常见误区”
  • 把 IO 当“新语法壳”，不重构订阅粒度。
  • 在 SSR 中保留模块级单例 store。
  • 忽略 snapshot 边界，直接传运行时实例。

下一步

Section titled “下一步”