我做前端三年了，目前在一家金融科技公司负责知识管理平台（KMS）的前端开发。我们的系统是一个 Lerna Monorepo，包含 Web

  端、Dashboard 后台和 H5 移动端，技术栈是 React 18 + TypeScript + Ant Design。

  刚接手这个项目时，状态管理选型让我纠结过。团队最终用了 MobX，踩了一年坑后，我想分享一些真实的体感。

  几个核心优势

  心智负担小

  MobX 的核心理念是"任何可以从应用状态推导出来的东西，都应该自动推导出来"。不需要写 action creator、reducer、selector，用

  makeAutoObservable 一个装饰器就搞定了整个 store。对于业务迭代快的项目，少写一层胶水代码就少出一层 bug。

  响应式天然精准

  我们平台有一个知识库编辑功能，基于 Tiptap

  富文本编辑器实现。一个页面同时展示树形目录、编辑器主体、标签面板、历史版本四个区域，每个都依赖同一个知识库 store。MobX

  的细粒度依赖追踪让只有真正用到那块数据的组件才会 re-render，不需要 React.memo 或 useMemo 手动优化。

  

  和 class 组件/对象思维天然契合

  大部分后端数据模型都是嵌套对象（比如知识库 → 分类 → 文档 → 标签 → 评论），MobX 的 observable

  对象可以直接映射这些结构，不需要像 Redux 一样拍平到 store 再通过 normalize 重组。

  不是没有坑

  响应式"魔法"在调试时是负担

  数据流不显式，出问题时你很难一眼看出是哪个组件触发了哪次状态变更。我们的解决方案是装了 MobX DevTools + 严格使用 action

  包裹所有修改，避免随处直接改 observable。

  团队新人上手有成本

  MobX 社区比 Redux 小得多，中文资料更是少。新同事进来可能要先花半天理解 computed、reaction、autorun

  的区别。我的做法是写了一套 store 模板，新功能照着模板写就行，不用从零理解。

  我的选型建议

  - 后台管理系统、数据密集型应用：MobX 很适合，开发效率高

  - 团队规模小、迭代快：MobX 的灵活性是优势

  - 需要强可预测性、严格架构规范：Redux (特别是 Redux Toolkit) 更合适

  - 两者混用也可以：全局状态用 MobX，服务端缓存用 React Query，各干各的

  前端状态管理没有银弹，选型本质上是权衡你的团队结构、项目规模和业务复杂度。希望这篇分享对正在纠结的同学有一点帮助。