Redux管理状态相较组件内状态，存在哪些额外变更限制？

嘿，我来帮你把这事儿掰扯清楚～你说得没错，组件内部管理状态时也非常推荐用不可变方式更新，但Redux对状态变更的限制要严格得多，属于「必须遵守」的规则，而不是「最佳实践」。

先回顾下组件内部的不可变更新例子 #

就拿你提到的状态 { count: 3, list: ['foo', 'bar', 'baz'] } 来说，组件内的正确更新方式是这样的：

// 类组件写法
this.setState(prevState => ({
  count: prevState.count + 1,
  list: [...prevState.list, 'new-item'] // 展开原数组生成新数组，添加新元素
}));

// 函数组件用useState的写法
const [state, setState] = useState({ count: 3, list: ['foo', 'bar', 'baz'] });
setState(prev => ({
  ...prev, // 展开原状态对象
  count: prev.count + 1,
  list: [...prev.list, 'new-item']
}));

核心原则就是绝不直接修改原状态对象/数组，而是生成新的引用，这样React才能正确检测到状态变化并触发重新渲染。

Redux额外的强制限制 #

Redux的设计目标是让状态变化完全可预测、可追踪，所以在状态更新上多了几个硬约束：

• 必须通过纯函数Reducer更新状态
  Reducer是唯一能修改store状态的入口，而且它必须是纯函数：

  1. 不能直接修改传入的state参数，必须返回全新的状态对象；
  2. 不能有任何副作用（比如发起异步请求、修改全局变量、调用Math.random()这类非纯操作）；
  3. 相同的输入（state + action）必须返回完全相同的输出。
     组件内部偶尔不小心改了原状态（比如直接state.list.push()），最多是渲染异常，但Redux里这么做会直接导致状态追踪失效，devTools的时间旅行功能也会彻底坏掉。

• 必须通过Dispatch Action触发更新
  你不能直接修改Redux store里的状态（比如store.getState().count = 4），必须先定义一个描述变化的action对象，再通过store.dispatch(action)来触发reducer执行。
  而组件内部可以直接调用setState或者useState的set函数，不需要经过这个中间流程。

• 不可变更新是硬性要求，没有例外
  组件内部有时候可能会有“投机取巧”的操作（比如直接修改原状态后调用setState({})强制更新），但Redux里这种操作完全行不通——因为Redux依赖状态的引用变化来判断是否需要通知订阅者，修改原状态不会产生新引用，所有依赖这个状态的组件都不会重新渲染，而且状态变化完全不可追踪。

一句话总结 #

组件内部的不可变更新是「推荐的最佳实践」，而Redux的不可变更新、纯Reducer、Action触发是「必须遵守的规则」，这都是为了保证Redux状态的可预测性和可调试性。

内容的提问来源于stack exchange，提问作者Dónal