React/Redux中为什么要dispatch action更新state而非直接修改store？

• 保证状态变更的可追溯性与可预测性
  Redux 核心设计是单向数据流，所有状态变更都由 action 触发，每一次修改都会留下明确的操作记录，包含变更原因、变更内容等信息。配合 Redux DevTools 可以直接回放所有操作、对比变更前后的状态，复杂项目排查问题的效率会高很多。如果直接修改 store，没有任何变更记录，出现状态异常时根本无法定位是哪一步操作修改了数据。
• 确保变更逻辑统一，避免脏数据
  所有状态变更逻辑都收敛在 reducer 纯函数中，相同输入永远返回相同输出，没有额外副作用。通过 dispatch 走 reducer 流程，所有修改都会遵守统一的业务规则，比如修改购物车商品数量时自动计算总价、校验数据格式等，不会出现漏更关联字段、写入非法数据的问题。直接修改 store 相当于跳过了所有规则校验，很容易产生数据不一致的问题。
• 能够正确触发组件响应式更新
  react-redux 等绑定库是通过监听 store 的合法变更事件来通知关联组件重渲染的，只有 dispatch 触发的、经过 reducer 处理的状态更新，才会被 store 的订阅机制感知到，进而驱动 UI 刷新。直接修改 store 属于原生对象属性修改，store 不会触发变更事件，依赖对应状态的组件完全不会更新，直接出现 UI 和数据不一致的 bug。
• 兼容 Redux 中间件生态
  redux-thunk、redux-saga、日志埋点、权限校验等中间件，都是基于 action 的派发流程做扩展的，所有中间件逻辑都会在 dispatch 过程中执行。直接修改 store 会跳过整个中间件链路，异步请求处理、日志打印、权限校验等逻辑都会完全失效。
• 遵守不可变数据原则，保障配套功能正常运行
  Redux 要求 state 是不可变的，每次更新都要返回全新的状态对象。直接修改原 store 的值属于可变操作，会破坏不可变原则，直接导致 DevTools 的时间旅行、状态对比功能失效，也会让 react-redux 的浅比较优化失效，出现不必要的重渲染或者该渲染时不渲染的异常。

举个实际场景的例子：你需要给购物车加一件商品，要求加购同时更新总金额。如果直接执行 store.cart.push(newProd)，总金额字段不会同步更新，UI 显示的价格依然是旧值；但通过 dispatch ADD_TO_CART action，reducer 会统一处理加购逻辑，同时更新商品列表和总金额两个字段，不会出现数据不一致的问题。

内容的提问来源于stack exchange，提问作者Anubhav kumar