⚡ 30 秒速记
- 核心判断：状态管理的核心是把状态变化约束成可追踪的数据流，中间件在派发边界扩展异步、日志和副作用
- 原理主线：围绕 「一、认识MobX」、「二、核心API」、「三、计数器例子」 建立输入、状态变化与输出之间的因果关系
- 文章范围：深入总结MobX的原理、核心API、与Redux的对比、优缺点及最佳实践，帮助前端开发者全面理解MobX在React中的应用与数据管理方式，提升项目开发效率与可维护性
- 边界与代价：集中式状态不是越多越好；可变性、订阅粒度和异步取消决定性能与可维护性
- 工程落地：选型要从状态归属、更新频率、调试需求和团队约束出发，而不是只比较 API 数量
MobX 本质上是基于运行时依赖追踪的响应式状态管理：读取 observable 的跟踪函数会建立订阅，数据变化后只通知相关计算或视图。 computed 适合带缓存的衍生值，observer 负责让组件响应更新，autorun 和 reaction 则用于日志、请求等副作用。状态虽然可以直接修改，但工程中通常配合 action 和严格模式约束写入入口，异步流程可用 flow 组织。要注意，跟踪函数之外或异步阶段读取的属性不会自动建立依赖；若业务逻辑难以封装进领域模型，Redux 可能更合适。
这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。
版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。
# 一、认识MobX
打印
mobx，看看mobx中有什么
MobX的整个流程
MobX 和 Redux 的比较
Redux是单一数据源，而MobX往往是多个store。MobX可以根据应用的UI、数据或业务逻辑来组织store，具体如何进行需要你自己进行权衡Redux store使用普通的JavaScript对象结构，MobX将常规JavaScript对象包裹，赋予observable的能力，通过隐式订阅，自动跟踪observable的变化。MobX是观察引用的，在跟踪函数中（例如：computed value、reactions等等），任何被引用的observable的属性都会被记录，一旦引用改变，MobX将作出反应。注意，不在跟踪函数中的属性将不会被跟踪，在异步中访问的属性也不会被跟踪Redux的state是只读的，只能通过将之前的state与触发的action结合，产生新的state，因此是纯净的（pure）。而MobX的state即可读又可写，action是非必须的，可以直接赋值改变，因此是不纯净的（Impure）Redux需要你去规范化你的state，Immutable数据使Reducer在更新时需要将状态树的祖先数据进行复制和更新，新的对象会导致与之connect的所有UI组件都重复渲染。因此Redux state不建议进行深层嵌套，或者需要我们在组件中用shouldComponentUpdate优化。而MobX只自动更新你所关心的，不必担心嵌套带来的重渲染问题
