MobX logo

MobX

基于信号(Signal)的响应式状态管理库,通过函数式响应编程让状态变化自动、精确地传播到所有依赖方。

精选工具状态管理JavaScriptReactVue

MobX 是 2016 年创建的响应式状态管理库,采用 Observable + 自动更新范式,以最少样板代码和透明依赖追踪著称。2024 年升级为基于信号的实现,支持框架无关(React/Vue/Angular),适合领域建模和交互密集型中大型应用。

MobX

基于信号(Signal)的响应式状态管理库,通过函数式响应编程(FRP)让状态变化自动、精确地传播到所有依赖方,实现简单且可扩展的状态管理。

技术简介说明

MobX 由 Michel Weststrate 于 2016 年创建,是 JavaScript/TypeScript 生态中最具影响力的响应式状态管理库之一。它的核心理念是:状态即数据,数据即可观察,变化即自动传播。MobX 将应用状态建模为一组可观察的(observable)数据源,任何读取这些数据的代码(计算值 computed、组件、reaction)都自动成为其依赖方;当数据变化时,所有依赖方自动、精确地更新,无需手动订阅或分发。

MobX 的哲学可以用一句话概括:"做任何事,只需最小化的样板代码"。与 Redux 的"单一 Store + 纯函数 Reducer + Action 分发"不同,MobX 采用双向响应式绑定——你直接修改状态(像写普通 JS 对象一样),MobX 自动追踪依赖图并触发所有下游更新。这种"透明的响应式"极大降低了心智负担,特别适合快速迭代的中小型项目和复杂交互场景。

MobX 从 v6 开始全面拥抱 ES2022 装饰器Proxy 机制,摒弃了旧版的 ES5 defineProperty 方案。截至 2026 年中,MobX 稳定版为 6.16.1,GitHub 约 28.2k stars,npm 周下载量约 230 万次,被大量企业级应用采用(包括 Mendix、Uber、Facebook/Meta 内部项目)。2024 年 MobX 官方定位从"响应式"升级为 "signal-based"(基于信号),与现代前端信号化趋势(Angular Signals、Vue Reactivity、Solid.js)对齐。

基本信息

项目详情
官网https://mobx.js.org
GitHubhttps://github.com/mobxjs/mobx
LicenseMIT
当前稳定版v6.16.1(2026 年 6 月 8 日发布)
GitHub Stars~28.2k(2026 年 7 月)
npm 周下载量~230 万次
主要维护者Michel Weststrate(@mweststrate,创建者,Meta 工程师)
TypeScript 支持原生 TypeScript,完整类型推导
包体积~16KB gzip(核心库)

快速上手

安装

# npm
npm install mobx
 
# yarn
yarn add mobx
 
# pnpm
pnpm add mobx

基础配置

在 React 项目中使用(最常见场景):

# 安装 React 绑定(mobx-react 包含 mobx-react-lite)
npm install mobx mobx-react
 
# 或使用轻量版(仅函数组件)
npm install mobx mobx-react-lite
 
# pnpm
pnpm add mobx mobx-react

装饰器支持(可选,需 Babel/SWC 配置):

# Babel 装饰器插件
npm install --save-dev @babel/plugin-proposal-decorators
 
# 或使用 SWC(推荐,更快)
# 在 .swcrc 中配置:
# "jsc": { "transform": { "legacyDecorator": true } }

注意:MobX 6+ 不强制使用装饰器,也可以通过 makeObservable / makeAutoObservable 函数式 API 实现相同功能。

浏览器 CDN:

<script src="https://cdn.jsdelivr.net/npm/mobx@6/dist/mobx.umd.production.min.js"></script>

最小示例

纯 JavaScript(无框架)示例:

import { makeAutoObservable } from 'mobx';
 
// 1. 定义 Store
class TodoStore {
  todos = [];
 
  constructor() {
    makeAutoObservable(this);
  }
 
  // computed 值——自动推导
  get completedCount() {
    return this.todos.filter(t => t.completed).length;
  }
 
  // action——修改状态
  addTodo(text) {
    this.todos.push({ text, completed: false, id: Date.now() });
  }
 
  toggleTodo(id) {
    const todo = this.todos.find(t => t.id === id);
    if (todo) todo.completed = !todo.completed;
  }
}
 
// 2. 创建实例
const store = new TodoStore();
 
// 3. 自动响应(reaction)
import { autorun } from 'mobx';
 
autorun(() => {
  console.log(`待办总数: ${store.todos.length}, 已完成: ${store.completedCount}`);
});
 
// 4. 修改状态——自动触发上面的日志
store.addTodo('学习 MobX');
// 输出: "待办总数: 1, 已完成: 0"
 
store.toggleTodo(store.todos[0].id);
// 输出: "待办总数: 1, 已完成: 1"

React 组件示例:

import React from 'react';
import { observer } from 'mobx-react';
import { makeAutoObservable } from 'mobx';
 
// Store
class CounterStore {
  count = 0;
 
  constructor() {
    makeAutoObservable(this);
  }
 
  increment() {
    this.count += 1;
  }
 
  get doubleCount() {
    return this.count * 2;
  }
}
 
const store = new CounterStore();
 
// 组件——用 observer 包裹
const Counter = observer(() => (
  <div>
    <p>计数: {store.count}</p>
    <p>双倍: {store.doubleCount}</p>
    <button onClick={() => store.increment()}>+1</button>
  </div>
));
 
export default Counter;

核心概念与架构

MobX 的架构建立在四个核心概念之上,它们构成了一条清晰的单向数据流:Action → Observable → Computed/Reaction → View

Observable(可观察状态)

Observable 是 MobX 中所有响应式数据的源头。它可以是一个基本类型值、对象属性、数组、Map 或 Set。当你把一个属性标记为 observable 后,MobX 会自动追踪谁在读它、谁在写它,并在值变化时通知所有观察者。

import { observable, makeAutoObservable } from 'mobx';
 
// 方式 1:函数式 API(推荐)
class Store {
  name = 'MobX';
  count = 0;
 
  constructor() {
    makeAutoObservable(this); // 自动将所有属性标记为 observable,方法为 action
  }
}
 
// 方式 2:observable() 包装
const state = observable({ count: 0, user: { name: 'Alice' } });

Computed(计算值)

Computed 是基于其他 observable 推导出的值,类似于 Vue 的计算属性或 Excel 公式。MobX 会缓存 computed 的结果,只有在其依赖的 observable 实际变化时才重新计算。没有任何组件观察时,computed 会自动挂起(suspend),不消耗计算资源。

class Store {
  firstName = '张';
  lastName = '三';
 
  constructor() {
    makeAutoObservable(this);
  }
 
  get fullName() {
    return this.firstName + this.lastName;
  }
}

Action(动作)

Action 是修改 observable 状态的函数。它本身不特殊,只是语义上标识"这里是修改状态的地方"。MobX 推荐通过 action 修改状态,这样可以获得更好的调试信息和性能(批量更新)。

class Store {
  count = 0;
 
  constructor() {
    makeAutoObservable(this);
  }
 
  increment() {
    this.count++; // 这是一个 action
  }
 
  // 异步 action
  async fetchData() {
    const data = await fetch('/api/data').then(r => r.json());
    this.count = data.count; // 异步 action 中修改状态
  }
}

Reaction(反应)

Reaction 是连接 observable 世界和副作用世界的桥梁。当依赖的 observable 变化时,reaction 自动执行副作用(如 DOM 更新、网络请求、日志等)。常见的 reaction 类型包括 autorunreactionwhen

import { autorun, reaction, when } from 'mobx';
 
// autorun:每次依赖变化都执行
const dispose = autorun(() => {
  console.log('当前计数:', store.count);
});
dispose(); // 手动清理
 
// reaction:只在特定数据变化时执行回调
reaction(
  () => store.count,           // 追踪函数
  (count) => console.log(`变为 ${count}`),  // 副作用
  { fireImmediately: true }    // 选项
);
 
// when:只在条件首次满足时执行一次
when(
  () => store.loaded === true,
  () => console.log('数据加载完成!')
);

架构全景

┌─────────┐    修改     ┌─────────────┐    推导     ┌────────────┐
│ Action  │ ──────────> │  Observable │ ──────────> │  Computed  │
│ (动作)   │            │  (可观察状态) │            │  (计算值)   │
└─────────┘            └──────┬──────┘            └──────┬─────┘
                              │                         │
                              │  通知                    │  依赖
                              ▼                         ▼
                       ┌─────────────┐          ┌────────────┐
                       │  Reaction   │          │   View     │
                       │  (副作用)    │          │  (UI 渲染)  │
                       └─────────────┘          └────────────┘

核心流程:Action 修改 Observable → Computed 自动重新推导 → Reaction/View 自动更新。整个过程完全自动,开发者无需手动订阅、无需 dispatch、无需 selector。

核心特性

1. 基于信号的响应式引擎

MobX 6+ 内部基于信号(Signal)机制实现,这是一种现代化的响应式原语。与传统的发布-订阅模式不同,MobX 的信号引擎能自动构建精确的依赖图,实现精确的、最小的更新粒度——只有真正读取了变化数据的组件才会重新渲染。

2. 最小化样板代码

MobX 最突出的特性是几乎零样板代码。你写的是普通的 JavaScript/TypeScript 类和对象,只需调用 makeAutoObservable(this) 一行代码即可将所有属性、计算值和方法变为响应式的。相比 Redux 需要定义 action type、reducer、selector,MobX 的代码量通常减少 60-80%。

3. 透明的依赖追踪

MobX 在运行时自动追踪每个 computed 和 reaction 的依赖关系。你不需要像 Vue 那样在 setup() 中显式声明依赖,也不需要像 Redux 那样写 selector。MobX 会在运行时通过 JavaScript 的 Proxy 机制拦截属性访问,自动建立依赖图。

4. Computed 自动缓存与挂起

Computed 值是惰性求值的:只有在被读取时才计算,且结果会被缓存。当依赖未变化时直接返回缓存值。更强大的是,当 computed 没有任何观察者时,MobX 自动将其挂起(suspend),停止追踪上游——这是内置的内存优化,无需手动管理。

5. 完善的 TypeScript 支持

MobX 6+ 对 TypeScript 的支持非常成熟,makeAutoObservable 能完整推导所有属性和方法的类型。装饰器语法在 TypeScript 5+ 中已稳定支持(Stage 3)。不需要额外的类型包装或映射类型。

6. 框架无关(Framework Agnostic)

MobX 核心库不绑定任何 UI 框架。它可以在 React、Vue、Preact、Svelte(通过 mobx-svelte)、Angular 等任何框架中使用,甚至可以在纯 Node.js 服务端或 Web Worker 中使用。React 绑定通过 mobx-react / mobx-react-lite 提供,Vue 绑定通过 mobx-vue 提供。

7. 多 Store 架构

MobX 天然支持多个独立的 Store,每个 Store 管理自己的状态领域。这与 Redux 的单一 Store 模式截然不同,更接近 Flux 的多 Store 理念,但更灵活——Store 之间可以互相引用,形成有向图。

8. 异步流程原生支持

MobX 的 action 天然支持异步操作。配合 flow(基于 Generator)或标准的 async/await,异步状态管理非常直观。配合 mobx-utilsfromPromise,可以优雅处理 Promise 的 pending/fulfilled/rejected 三态。

9. 开发者工具

MobX 提供 Chrome DevTools 扩展(MobX Developer Tools),支持实时查看 observable 树、computed 依赖图、action 调用历史。2026 年 6 月仍在活跃更新(v0.9.33)。

10. 持久化与序列化

通过 mobx-state-tree 的快照(snapshot)机制或 mobx-persist-store 等社区库,可以轻松实现状态的持久化存储(localStorage、IndexedDB)和跨网络传输。

生态图

MobX 拥有一个围绕核心库构建的完整生态系统:

                          ┌──────────────────┐
                          │     MobX Core     │
                          │  (响应式引擎核心)   │
                          └────────┬─────────┘
                                   │
              ┌───────────────┬────┴────┬───────────────┐
              │               │         │               │
     ┌────────▼──────┐  ┌────▼─────┐  ┌▼────────┐  ┌──▼──────────┐
     │  框架绑定层    │  │ 状态管理  │  │ 工具库  │  │ 开发者工具   │
     │               │  │ 增强层   │  │         │  │             │
     ├───────────────┤  ├──────────┤  ├─────────┤  ├─────────────┤
     │ mobx-react    │  │ mobx-    │  │ mobx-   │  │ MobX Dev-   │
     │ mobx-react-   │  │ state-   │  │ utils   │  │ tools       │
     │   lite        │  │ tree     │  │         │  │ (Chrome     │
     │ mobx-vue      │  │ mobx-    │  │ mobx-   │  │  Extension) │
     │ mobx-preact   │  │ keystone │  │ persist │  │             │
     │ mobx-angular  │  │          │  │ mobx-   │  │             │
     └───────────────┘  └──────────┘  │ tanstack│  └─────────────┘
                                      │ -query  │
                                      └─────────┘

生态组件详解

包名用途说明
mobx核心库响应式引擎,包含 observable、computed、action、reaction 等
mobx-reactReact 绑定(完整版)提供 observer HOC、Provider/inject 模式
mobx-react-liteReact 绑定(轻量版)仅提供函数组件的 observer,约 2KB
mobx-state-tree结构化状态管理基于 MobX 的"电池全装"方案,支持类型系统、快照/补丁、中间件
mobx-keystone树形状态管理TypeScript 优先的 MST 替代方案,支持快照、补丁、引用
mobx-utils工具集提供 fromPromisefromResourcekeepAlivelazyObservable 等实用函数
mobx-persist-store状态持久化将 MobX Store 自动持久化到 localStorage/sessionStorage
mobx-react-observer编译器插件Babel/SWC 插件,自动为 React 组件添加 observer
MobX Developer Tools浏览器扩展Chrome DevTools 中可视化 observable、action 和 reaction

适用场景

1. 中大型交互密集型应用

MobX 最适合 UI 状态复杂、交互频繁的中大型应用——如表单系统、仪表盘、编辑器、实时协作工具等。它的精确更新粒度和自动依赖追踪能大幅减少手动优化工作。

2. 领域模型驱动的业务系统

MobX 的 class-based Store 设计天然适合面向对象建模。当你的应用有清晰的业务实体(用户、订单、商品等)且需要封装行为时,MobX 的 Store 模式比 Redux 的扁平状态切片更自然。

3. 实时数据流应用

WebSocket 推送、轮询数据、实时图表——MobX 的 reaction 机制能优雅地将外部数据流映射到 UI,无需额外的状态同步代码。配合 mobx-utilsfromPromise/fromResource 处理异步数据源非常方便。

4. 已有代码库的渐进式集成

MobX 不要求"全局接管"状态管理。你可以只在需要响应式的部分引入 MobX Store,与 React 的 useState/useReducer 甚至 Redux 共存。这种低侵入性使其成为遗留系统改造的理想选择。

5. 需要共享状态但不想引入 Redux 复杂度的项目

如果你的项目需要跨组件/跨页面共享状态,但 Redux 的 boilerplate(action type、reducer、selector、middleware)让你觉得过重,MobX 是更轻量的替代方案。

6. TypeScript 优先的项目

MobX 6+ 的 TypeScript 支持非常成熟,不需要额外的类型定义或映射。配合 class-based Store,可以获得完整的 IDE 自动补全和类型检查。

7. 非 React 框架项目

MobX 核心库是框架无关的,可以在 Vue、Preact、Angular、甚至纯 DOM 操作中使用。如果你的团队需要在多个框架间共享状态管理逻辑,MobX 提供了一致的 API 体验。

开发与工程化

TypeScript 配置

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "experimentalDecorators": true,      // 使用装饰器语法时需要
    "useDefineForClassFields": false     // 装饰器与类字段配合需要
  }
}

注意:如果不使用装饰器(通过 makeAutoObservable 函数式 API),则不需要上述额外配置。

Babel 配置(使用装饰器)

// babel.config.json
{
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "version": "2023-11" }]
  ]
}

开发环境配置

// 开发环境下启用 MobX 严格模式(只允许通过 action 修改状态)
import { configure } from 'mobx';
 
configure({
  enforceActions: 'observed',  // 所有 observable 都必须通过 action 修改
  computedRequiresReaction: process.env.NODE_ENV === 'development',  // computed 不应在 reaction 外被读取
  reactionRequiresObservable: process.env.NODE_ENV === 'development', // reaction 必须有 observable 依赖
  observableRequiresReaction: process.env.NODE_ENV === 'development', // observable 不应在 render 外读取
  disableErrorBoundaries: process.env.NODE_ENV === 'development',
});

构建与打包

// Vite 配置
import { defineConfig } from 'vite';
 
export default defineConfig({
  esbuild: {
    // 如果需要装饰器支持
    tsconfigRaw: {
      compilerOptions: {
        experimentalDecorators: true,
      },
    },
  },
});

测试

// Vitest/Jest 测试示例
import { makeAutoObservable, runInAction } from 'mobx';
 
test('counter store increments correctly', () => {
  class CounterStore {
    count = 0;
    constructor() { makeAutoObservable(this); }
    increment() { this.count++; }
  }
 
  const store = new CounterStore();
  expect(store.count).toBe(0);
  store.increment();
  expect(store.count).toBe(1);
});
 
// 异步 action 测试
test('async action updates state', async () => {
  class DataStore {
    data = null;
    loading = false;
    constructor() { makeAutoObservable(this); }
    async fetchData() {
      this.loading = true;
      const result = await fetchMock();
      runInAction(() => {
        this.data = result;
        this.loading = false;
      });
    }
  }
 
  const store = new DataStore();
  await store.fetchData();
  expect(store.loading).toBe(false);
  expect(store.data).toBeDefined();
});

性能与安全

性能特性

优势:

  • 精确更新粒度:MobX 通过依赖追踪实现组件级别的精确更新,只有真正读取了变化数据的 observer 组件才重新渲染,无需 React.memouseMemo 手动优化。
  • Computed 惰性缓存:computed 值只在被读取时计算,且缓存直到依赖变化。当无人观察时自动挂起,不消耗资源。
  • 批量更新:在同一个 action 中对多个 observable 的修改会被自动批处理,只触发一次下游更新。
  • 写入性能:MobX 的 observable 写入是 O(1) 的直接赋值,不经过 reducer 分发链。

注意事项:

  • 写入时通知:MobX 在写入时同步通知所有观察者(包括更新 computed 缓存),对于超高频写入场景(如 60fps 动画)可能需要 action 包装或使用 runInAction 批处理。
  • Proxy 开销:每个 observable 对象都是 Proxy 包装,对于超大数组(>10000 元素)的频繁修改,Proxy 拦截可能带来额外开销。

内存管理

场景风险解决方案
keepAlive: true computedcomputed 永不过期,阻塞垃圾回收仅在真正需要全局生命周期的 computed 上使用
未 dispose 的 reactionautorun/reaction/when 持续持有引用必须调用返回的 dispose() 函数
闭包捕获 store匿名函数捕获大对象,阻止 GC在 useEffect 返回函数中清理
大型 observable 集合Proxy 元数据占内存对超大数据集考虑分页或懒加载

安全考量

  • XSS 防护:MobX 本身不处理 UI 渲染,XSS 防护由 React 等框架的转义机制保证。MobX Store 中存储的原始数据不会自动转义。
  • 状态篡改:MobX Store 默认不加密或签名,存储在客户端的状态可被用户修改。敏感数据(如认证 token)应配合加密存储。
  • SSR 安全:在 SSR 环境中,每个请求需要独立的 Store 实例,避免跨请求状态泄漏。使用 mobx-reactProvider 模式确保隔离。

技术对比

与主流状态管理库对比

特性MobXReduxZustandValtioMobX-State-Tree
核心理念响应式 FRPFlux 单向流轻量 FluxProxy 可变结构化树模型
范式Observable + 自动更新Store + Reducer + DispatchStore + Set 函数Proxy + 直接修改类型化模型 + Action
Boilerplate极少较多(RTK 简化)极少极少中等
更新机制精确依赖追踪全量对比 + selector精确订阅Proxy 自动追踪精确依赖追踪
TypeScript原生支持需额外类型原生支持原生支持类型推导较强
包体积~16KB gzip~7KB (core)~1KB~3KB~22KB
DevToolsChrome 扩展Redux DevTools(最强)复用 Redux DevToolsChrome 扩展Chrome 扩展
中间件有限丰富( thunk, saga, epic)有限(immer 集成)中间件系统
学习曲线中等陡峭较高
多 Store原生支持单 Store(slice 模拟多)原生支持原生支持原生支持
框架绑定React, Vue, Preact, AngularReact(其他社区)React(其他社区)React(其他社区)React
社区活跃度(2026)稳定维护最活跃最活跃(增速第一)中等稳定维护
npm 周下载量~230 万~900 万~500 万~50 万~30 万

选型建议

场景推荐方案理由
小型应用、简单全局状态Zustand最低学习成本,API 极简
中大型 React 应用、团队大Redux Toolkit生态最完善,DevTools 最强
交互密集型、领域建模MobX响应式 + OOP + 自动依赖追踪
极致轻量、原子化状态Jotai / Valtio原子粒度或代理直接修改
需要快照/补丁/时间旅行MobX-State-Tree结构化状态 + 完整快照系统
复杂异步流、副作用管理Redux + RTK Query内建数据获取和缓存
Vue 应用Pinia(官方推荐)Vue 生态原生集成

最佳实践

1. 优先使用 makeAutoObservable

// ✅ 推荐——一行搞定,自动推断所有属性
class UserStore {
  name = '';
  age = 0;
 
  constructor() {
    makeAutoObservable(this);
  }
 
  get isAdult() { return this.age >= 18; }
  setName(name) { this.name = name; }
}
 
// ❌ 不推荐——手动标注每个属性(除非需要精细控制)
class UserStore {
  name = observable.ref('');
  // ...
}

注意:makeAutoObservable 不能用于有 super 的子类。继承场景使用 makeObservable(this, &#123; name: true, ... &#125;)

2. 始终通过 action 修改状态

// ✅ 推荐
store.name = 'Alice'; // 在 action 中修改(严格模式下必须在 action 中)
 
// ❌ 避免(在 action 外部直接修改)
// 如果开启了 enforceActions,会抛出错误

3. 避免在 observer 组件中过早解构

// ❌ 错误——解构后失去响应性
const UserCard = observer(({ store }) => {
  const { name, age } = store; // 解构基本类型,断开追踪
  return <p>{name} - {age}</p>;
});
 
// ✅ 正确——在 render 内部直接访问
const UserCard = observer(({ store }) => {
  return <p>{store.name} - {store.age}</p>; // 保持响应性
});
 
// ✅ 也可以——解构对象引用仍保持响应性
const UserCard = observer(({ store }) => {
  const { user } = store; // user 是对象引用,仍然响应式
  return <p>{user.name}</p>;
});

4. 异步 action 中使用 runInAction

class DataStore {
  data = null;
  loading = false;
 
  constructor() { makeAutoObservable(this); }
 
  // ✅ 推荐——使用 flow
  fetchData = flow(function* () {
    this.loading = true;
    try {
      const result = yield fetch('/api/data').then(r => r.json());
      this.data = result;
    } finally {
      this.loading = false;
    }
  });
 
  // ✅ 也可以——async + runInAction
  async fetchDataAsync() {
    this.loading = true;
    try {
      const result = await fetch('/api/data').then(r => r.json());
      runInAction(() => {
        this.data = result;
        this.loading = false;
      });
    } catch (e) {
      runInAction(() => { this.loading = false; });
    }
  }
}

5. 及时清理 reaction

// ✅ 在 useEffect 中清理
useEffect(() => {
  const dispose = autorun(() => {
    console.log('count:', store.count);
  });
  return dispose; // 组件卸载时清理
}, []);
 
// ✅ 使用 when 一次性监听
useEffect(() => {
  return when(
    () => store.ready,
    () => console.log('准备好了!')
  );
}, []);

6. 合理拆分 Store

// ✅ 推荐——按领域拆分
class UserStore { /* 用户相关状态 */ }
class OrderStore { /* 订单相关状态 */ }
class CartStore { /* 购物车相关状态 */ }
 
// Store 之间可以互相引用
class AppStore {
  userStore;
  orderStore;
  cartStore;
 
  constructor() {
    this.userStore = new UserStore();
    this.orderStore = new OrderStore(this);
    this.cartStore = new CartStore(this);
    makeAutoObservable(this);
  }
}
 
// ❌ 避免——单个巨大 Store
class MegaStore {
  // 100+ 属性和方法...
}

7. 避免使用 keepAlive 除非有充分理由

// ❌ 滥用 keepAlive——computed 永不释放
class Store {
  get expensiveData() {
    return computeExpensiveResult(this.rawData);
  }
}
// 如果设置 @computed({ keepAlive: true }),即使无人读取也会持续计算
 
// ✅ 让 computed 自然挂起——无人观察时自动释放
class Store {
  get expensiveData() {
    return computeExpensiveResult(this.rawData);
  }
  // MobX 自动管理生命周期,无需 keepAlive
}

技术局限与边界

已知局限

局限详细说明影响程度
社区趋势偏移2025-2026 年 Zustand 和 Jotai 增速明显超过 MobX,新项目选择 MobX 的比例下降中等
React Compiler 兼容性MobX 的 observer 模式与 React Compiler(React Forget)的自动 memoization 存在冲突(GitHub #3874),需要额外的 mobx-react-observer Babel/SWC 插件适配
隐式依赖追踪不透明依赖关系在运行时动态建立,调试时不如 Redux 的 selector 显式,新手容易踩"未包裹 observer"的坑中等
装饰器依赖 Babel/SWC 配置虽然 MobX 6+ 不强制装饰器,但很多示例和库仍基于装饰器,增加了初始配置复杂度
写入时全量通知修改一个 observable 会同步通知所有下游(更新 computed + 触发 reaction),高频写入场景可能成为瓶颈中等
Proxy 内存开销每个 observable 对象都是 Proxy,大型数据集(数万节点)的内存开销约为原生 JS 对象的 2-10 倍中等
DevTools 不如 ReduxMobX DevTools 功能较弱,不支持时间旅行调试(time-travel),Redux DevTools 生态更成熟中等
学习曲线虽然比 Redux 简单,但 observable/computed/reaction/action 四概念 + Proxy 原理 + 装饰器语法仍有一定学习门槛
React 生态边缘化风险随着 React Server Components 和 Server Actions 的普及,客户端状态管理的重要性在下降,MobX 在新 React 项目中的存在感减弱中等

边界场景

  • 不适合纯服务端渲染(SSR)框架:MobX 的核心价值在客户端响应式更新,SSR-only 或静态站点无需 MobX。
  • 不适合极简项目:对于只有几个 useState 就能搞定的小项目,引入 MobX 是过度设计。
  • 不适合需要时间旅行调试的场景:MobX 不支持像 Redux 那样的状态时间旅行。如果需要完整的历史状态回放,考虑 MobX-State-Tree 或 Redux。
  • 不适合函数式编程偏好者:MobX 基于类和可变状态的 OOP 风格,如果你偏好纯函数、不可变数据,Redux 或 Jotai 更合适。

学习资源

官方文档

资源链接说明
MobX 官方文档https://mobx.js.org最权威的学习入口,含 Getting Started、API 参考、最佳实践
10 分钟入门mobx.js.org/getting-started快速了解核心概念的最小教程
MobX 中文文档https://cn.mobx.js.org官方中文翻译
React 集成指南mobx.js.org/react-integrationReact + MobX 最佳实践

书籍

书名作者说明
《Taming the State in React》Robin Wieruch覆盖 Redux + MobX 两种方案的状态管理经典
《MobX Quick Start Guide》Pavan Podila, Michel WeststrateMobX 官方推荐的快速入门指南

视频课程

课程平台说明
State Management with MobXLinkedIn Learning2024 年更新的视频课程,适合中级开发者
Manage Complex State in React Apps with MobXegghead.ioMichel Weststrate 亲自录制

社区资源

资源链接说明
MobX GitHub Discussionsgithub.com/mobxjs/mobx/discussions官方讨论区,活跃的问题解答社区
MobX Awesome 列表GitHub mobxjs 组织社区贡献的扩展库、示例项目和工具集合
Stack Overflow [mobx]stackoverflow.com/questions/tagged/mobx大量历史 Q&A

2026 年现状

版本与生态状态

截至 2026 年 7 月,MobX 处于稳定维护期

  • 最新版本:v6.16.1(2026 年 6 月 8 日),主要改进了 Stage 3 装饰器支持和子类 override 能力。
  • GitHub Stars:~28.2k,增长放缓但基数庞大。
  • npm 周下载量:~230 万次,依然是下载量最大的状态管理库之一。
  • MobX 7:已在 GitHub 上有路线图(Issue #3796),计划移除废弃 API、更新构建系统,但暂无重大功能变更。目前仍处于规划阶段。

社区与生态趋势

挑战与变化:

  1. 市场占比下降:根据 2025-2026 年多项调研,Zustand 已超越 Redux 成为新项目首选,MobX 排名进一步靠后。在新建 React 项目中,MobX 的选择率约 10-15%,远低于 Zustand 的 30%+ 和 Redux 的 25%+。

  2. React Compiler 兼容性:MobX 的 observer 模式与 React Compiler 存在兼容性问题(Issue #3874)。社区已推出 mobx-react-observer Babel/SWC 插件作为过渡方案,但长期兼容性仍是未完全解决的问题。

  3. RSC(React Server Components)影响:随着 React 生态向 Server Components 迁移,客户端状态管理的整体重要性在下降。MobX 作为纯客户端方案,在 RSC 架构中的适用场景变窄。

  4. 信号化浪潮:Angular Signals、Vue Reactivity、Solid.js 原生信号、Svelte 5 Runes——"信号"已成为前端框架的标配。MobX 虽然自称"signal-based",但其核心设计理念比这些框架更"厚重",在轻量信号竞赛中不占优势。

优势与机会:

  1. 存量市场庞大:大量企业级应用(金融、电商、ERP)使用 MobX,这些项目短期内不会迁移。MobX 的维护和更新仍有稳定需求。

  2. MST 不可替代性:MobX-State-Tree 的快照/补丁/类型化模型在需要结构化状态管理的场景中(如 CRDT、离线优先应用)仍无明显替代。

  3. 框架无关性:在需要跨框架(React + Vue)共享业务逻辑的场景中,MobX 核心库的框架无关性仍是独特优势。

  4. 稳定性与成熟度:经过 10 年迭代,MobX API 已非常稳定,破坏性变更极少,适合追求长期稳定性的企业项目。

总结

MobX 在 2026 年依然是 JavaScript 状态管理领域最成熟、最完善的响应式方案之一。它不会消失,但也不再是"热门选择"——它更像是一个经过时间验证的可靠工具,适合特定场景(领域建模、交互密集型、OOP 风格)和存量项目维护。对于新项目,除非团队有 MobX 经验或明确的 OOP 建模需求,否则 Zustand/Jotai 通常是更"主流"的选择。