Redux强调唯一数据源与不可变更新，状态存于单一store，变更需通过纯函数reducer返回新对象；MobX主张响应式透明与面向对象建模，用observable自动追踪依赖并触发更新。
Redux强调“唯一数据源”和“不可变更新”
Redux把整个应用的状态存放在一个单一的store里，所有状态变更必须通过纯函数reducer完成，且不允许直接修改原状态——必须返回新对象。这种设计强制开发者明确描述“什么发生了变化”以及“如何安全地变化”，让状态演进可预测、可回溯、易调试。
典型操作流程是：dispatch action → 经过reducer计算 → 生成新state → 触发视图更新。中间件（如redux-thunk、red
ux-saga）用于处理异步逻辑，但它们不破坏“同步reducer”的核心约束。
MobX主张“响应式透明”和“面向对象建模”
MobX把状态封装成可观察对象（observable），当状态被访问（@observer组件中读取）或修改时，自动建立依赖关系。只要状态变化，所有依赖它的计算属性（computed）和副作用（reaction）就会被精准触发，无需手动指定更新范围。
它不强制统一store结构，允许你按业务域组织多个store类，用class + decorator方式自然表达状态与行为的关系。例如：
class TodoStore {
@observable todos = [];
@computed get completedCount() { return this.todos.filter(t => t.done).length; }
@action addTodo(text) { this.todos.push({ text, done: false }); }
}
根本分歧在于对“变化”的抽象方式
- Redux认为：状态变化是离散事件流，应显式建模为action类型+payload，适合复杂协作、强审计需求的场景
- MobX认为：状态变化是属性级响应链，应隐式追踪依赖，贴近直觉，开发效率高，适合快速迭代、UI交互密集的应用
- Redux的调试优势来自时间旅行、action日志等工具链；MobX的优势在于更少样板代码、更自然的状态组织方式
选型关键看团队习惯和项目特征
如果项目需要严格的状态变更记录、多人协同定义接口、或已有成熟Redux生态（如RTK Query），Redux仍是稳健选择。如果团队倾向OOP、重视开发速度、状态逻辑天然分散在多个领域模型中，MobX（或其现代替代品MobX-Light / Zustand）往往更轻量自然。
