dva、Redux Toolkit 与 MobX 选型对比：React 状态管理怎么选

图 0：dva、Redux Toolkit 与 MobX 三大状态管理方案核心定位全景

三种方案的核心思想与定位

React 本身只负责基于 Props 和 State 构建视图树。随着业务层级加深，跨组件状态共享促生了不同范式的状态管理工具。理解 dva、Redux Toolkit 与 MobX 的设计初衷，是进行客观技术选型的基础。

1. dva：Model 驱动的集中式封装体系

dva 是蚂蚁金服早年开源的轻量级前端应用框架，其核心是将当时相对割裂的 redux、redux-saga 以及 react-router 进行一体化打包。dva 最显著的特征是推行了 Model 概念，将某个领域模型内的 state（状态）、reducers（同步修改器）、effects（基于 Generator 的异步副作用）与 subscriptions（数据订阅）集中放置在单个对象内。

在早年原生 Redux 样板代码繁琐、异步中间件配置复杂的背景下，dva 极大地简化了中后台项目的搭建流程，并深度内嵌到了 Umi 框架中。但其副作用强依赖 Generator 函数，全局命名空间依赖字符串匹配，在现代 TypeScript 强类型支持和代码重构方面存在天然短板。

2. Redux Toolkit (RTK)：现代单向不可变数据流的标准规范

Redux Toolkit 是 Redux 官方团队为了彻底解决“Redux 样板代码过多、配置繁琐、包依赖碎片化”等痛点推出的现代标准工具包。RTK 内部集成了 Immer，让开发者能够以看似直接修改对象（“可变写法”）的方式，在底层生成完全不可变的快照新树。

此外，RTK 提供了 createSlice 统一管理 Action 和 Reducer，集成了 createAsyncThunk 规范化异步生命周期（pending、fulfilled、rejected），并内置了强大的数据请求与缓存方案 RTK Query。RTK 是完全基于 TypeScript 构建的，提供了完备的类型推断支持与 DevTools 时间旅行调试能力。

3. MobX：透明响应式与可变数据模型

与 Redux 家族强调“单向数据流与不可变快照”完全不同，MobX 遵循“响应式编程（Reactive Programming）”理念。它的核心哲学是：任何源自应用状态的东西都应该自动获得更新。

在 MobX 6 中，状态通常由普通的 JavaScript 类或对象构成，通过 makeAutoObservable 进行包装，底层基于 ES6 Proxy 实现依赖收集。组件通过 observer 包裹后，只要在 render 期间读取了某个状态属性，就会自动建立订阅关系。当数据发生修改时，仅有真正使用了该属性的组件才会重渲染，无需开发者手动编写浅比对逻辑或切片选择器。

图 1：三大方案从视图触发到状态生效的架构链路对比

响应机制与数据范式深度剖析

选型的核心分歧在于底层的数据处理机制：是遵循不可变数据（Immutability）进行引用比对，还是基于响应式拦截（Reactivity）自动追踪依赖。

不可变单向流机制 (Redux Toolkit / dva)

在 Redux 体系中，应用状态树是只读的。任何状态变更都必须派发一个显式的 Action 对象，由纯函数 Reducer 计算并返回全新的 State 引用。React 组件通过 useSelector 订阅状态时，React-Redux 会在上层状态变化时执行选择器，并通过引用相等性比对（严格全等 ===）决定是否触发组件重渲染。

RTK 引入 Immer 之后，避免了手写繁琐的展开运算符（{ ...state, user: { ...state.user, age: 25 } }）。但其本质依然是不可变快照，每一次修改都留下了清晰的历史轨迹，为异常排查、日志复现与时间旅行提供了坚固基石。

响应式透明收集机制 (MobX)

MobX 将数据变成了可观察对象（Observable）。当组件执行渲染逻辑时，MobX 运行在一个响应上下文中，通过 Proxy 的 get 陷阱记录当前组件使用了哪些字段；当业务代码执行赋值操作（通过 Action 修改属性）时，Proxy 的 set 陷阱捕获变更，并直接精确通知依赖了该字段的观察者执行刷新。

这种机制带来两个显著特点：

• 细粒度渲染性能出色：在具有成百上千个表单项、复杂联动表格或图元节点的界面中，修改单个数据节点只会触发对应的子组件重渲染，外部父组件完全不会参与无谓的比对计算。
• 隐式依赖带来排查隐患：数据是就地可变（Mutable）的，如果缺乏严格的代码规范，多处业务逻辑同时读写共享对象可能导致不可预料的副作用，追查“状态到底是在哪一步被篡改”相比严格单向流要困难得多。

图 2：不可变数据快照模式与响应式依赖追踪机制的内部运作原理

样板代码与异步处理实操对比

在日常开发中，状态管理最频繁承载的任务就是处理网络请求、维护 Loading 状态以及把数据写入 Store。以下分别展示同一个“根据用户 ID 获取用户信息并更新”的典型场景在三种方案中的具体实现代码。

1. dva 方案代码组织

dva 依赖 Generator 函数编写异步 Effect，通过 call 调用异步接口，通过 put 触发同 Model 内的 Reducer。

// dva model: userModel.js
export default {
  namespace: 'user',
  state: {
    userInfo: null,
    loading: false,
  },
  reducers: {
    saveUser(state, { payload }) {
      return { ...state, userInfo: payload, loading: false };
    },
    setLoading(state, { payload }) {
      return { ...state, loading: payload };
    },
  },
  effects: {
    *fetchUser({ payload: userId }, { call, put }) {
      yield put({ type: 'setLoading', payload: true });
      try {
        const response = yield call(fetchUserApi, userId);
        yield put({ type: 'saveUser', payload: response.data });
      } catch (error) {
        yield put({ type: 'setLoading', payload: false });
      }
    },
  },
};

在组件中，需要通过 dispatch({ type: 'user/fetchUser', payload: 123 }) 调用。由于类型系统无法直接将字符串 'user/fetchUser' 关联到 payload 参数类型，在大型项目中很容易出现参数漏传或拼写错误。

2. Redux Toolkit 方案代码组织

RTK 使用 createAsyncThunk 抽象异步任务，在 extraReducers 中由构建器语法处理三种状态，TypeScript 类型可全程自动推导。

// userSlice.ts
import { createSlice, createAsyncThunk, PayloadAction } from '@reduxjs/toolkit';

interface UserState {
  userInfo: { id: string; name: string } | null;
  loading: boolean;
}

const initialState: UserState = { userInfo: null, loading: false };

export const fetchUser = createAsyncThunk(
  'user/fetchUser',
  async (userId: string) => {
    const response = await fetchUserApi(userId);
    return response.data;
  }
);

export const userSlice = createSlice({
  name: 'user',
  initialState,
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchUser.pending, (state) => {
        state.loading = true;
      })
      .addCase(fetchUser.fulfilled, (state, action) => {
        state.loading = false;
        state.userInfo = action.payload; // 基于 Immer，直观修改
      })
      .addCase(fetchUser.rejected, (state) => {
        state.loading = false;
      });
  },
});

export default userSlice.reducer;

在组件中调用为：dispatch(fetchUser('123'))。如果参数不是 string 类型，TypeScript 会直接提示语法报错，工程严谨度显著提升。

3. MobX 方案代码组织

MobX 使用面向对象风格，代码最贴近原生 JavaScript 异步逻辑。需注意：在 await 之后的赋值语句若处于严格模式下，需包裹在 runInAction 中。

// UserStore.ts
import { makeAutoObservable, runInAction } from 'mobx';

export class UserStore {
  userInfo: { id: string; name: string } | null = null;
  loading = false;

  constructor() {
    makeAutoObservable(this);
  }

  async fetchUser(userId: string) {
    this.loading = true;
    try {
      const response = await fetchUserApi(userId);
      runInAction(() => {
        this.userInfo = response.data;
        this.loading = false;
      });
    } catch (error) {
      runInAction(() => {
        this.loading = false;
      });
    }
  }
}

export const userStore = new UserStore();

在组件中，直接通过 userStore.fetchUser('123') 执行。只要组件包裹了 observer，当 this.loading 或 this.userInfo 改变时，组件便会自动刷新。

图 3：异步网络数据获取在三大方案中的时序步骤与控制开销

选型核心维度横向评估

在架构设计中，没有绝对完美的工具，只有适合团队背景与业务形态的权衡。我们可以从五个核心工程维度进行综合对照：

图 4：三大方案在五大核心工程维度的评估矩阵

1. 团队规模与协作约束

当研发团队超过 10 人或跨多个部门协作时，Redux Toolkit 的优势最为突出。Redux 的单向数据流与 Action 结构是强制规范，无论代码由初级工程师还是资深专家编写，其数据流动路径是高度一致的。而 MobX 赋予了开发者极高的自由度，若团队内部没有建立健全的架构分层规范（如禁止在组件中直接修改 Store 属性、必须使用 Action 等），很容易随着业务迭代演变成四处变异数据的“意大利面条式”代码。

2. 调试诊断与状态追溯

Redux Toolkit 配合 Redux DevTools 可以提供业界最完整的时间旅行调试功能。每个 Action 的发起时刻、携带参数、前后的 State Diff 快照一目了然，甚至可以直接导出状态在本地重现偶发 Bug。相比之下，MobX 尽管也有官方开发工具，但由于对象就地修改的机制，在追溯多层嵌套变更的历史轨迹时体验略逊一筹。

3. TypeScript 契合度

RTK 与 MobX 6 均能带来一流的 TypeScript 体验。RTK 的切片、Reducer 和 Action 具有无缝的强类型约束，重构变量时可以获得全局 IDE 重命名支持。MobX 则天然契合 Class 声明。而 dva 的 Model 定义中，多处依赖弱类型的字符串标识（如 effects 中的 yield call、dispatch 字符串），在现代强类型工程中维护成本较高。

React 状态管理选型决策路径与落地建议

综合项目背景、团队特点与交互模式，可以按照如下决策路径快速定位最合适的状态管理库：

图 5：React 项目状态管理选型落地决策路径

场景建议与选型结论

• 推荐首选 Redux Toolkit 的场景：
  • 企业级中大型 SaaS 系统、复杂多角色权限平台、多人协同开发工程；
  • 状态结构复杂，跨页面联动繁多，对状态变更追溯有严苛要求；
  • 全面拥抱 TypeScript，希望获得最完备的强类型推导与官方持续维护支持。
• 推荐选用 MobX 的场景：
  • 富交互前端应用，如可视化大屏、图编辑器、拖拽式低代码平台、高频实时交易面板；
  • 状态之间存在大量的计算属性与衍生关系（Computed 缓存机制极佳）；
  • 中小型敏捷团队，追求快速迭代交付，希望用最少样板代码实现功能。
• 关于 dva 的处理建议：
  • 如果是正在稳定运行的 Umi 2/Umi 3 存量老项目，保持原有 dva 架构继续维护即可，无需盲目全量重写；
  • 对于存量项目的新功能模块，可以借助 Umi 新版插件逐步尝试引入轻量方案或过渡到 RTK；
  • 任何全新立项的现代 React 项目，均不建议新建基于 dva 的状态层。

在实际架构设计中，状态还可以合理分层：简单的服务端数据拉取与缓存可以直接交由 React Query 或 RTK Query 完成，纯局部 UI 交互保留在 React 本地状态中，全局状态库仅用于沉淀真正的核心跨组件业务领域状态，这样能让整个前端系统的代码保持清晰精简。