React中更新状态前直接修改对象为何不可取？

你提到的这种直接修改原状态对象再通过浅拷贝触发渲染的写法，除了定时器导致的状态 stale 问题外，还有不少容易被忽略的隐患：

• 破坏状态不可变性，引发组件渲染不一致
  React的props和状态更新依赖引用对比来判断是否需要重新渲染。当你直接修改object.b.c.a时，object.b.c的引用并没有改变——如果有子组件接收object.b.c作为props，React会认为props没有变化（引用相等），不会触发子组件的重新渲染，导致子组件显示的内容和父组件状态不一致。

比如这个例子：

function Child({ data }) {
  return <div>子组件显示：{data.a}</div>;
}

function Parent() {
  const [object, setObject] = useState({a: {b: {c: {a: 'a'}}}});

  const update = () => {
    // 直接修改原状态
    object.b.c.a = 'new value';
    // 浅拷贝触发父组件渲染
    setObject({...object});
  };

  return (
    <>
      <button onClick={update}>修改值</button>
      <div>父组件显示：{object.b.c.a}</div>
      <Child data={object.b.c} />
    </>
  );
}

点击按钮后，父组件会更新显示new value，但子组件的data引用还是旧的object.b.c，所以不会重新渲染，依然显示a，出现界面不一致的bug。

• 调试难度飙升
  React DevTools会记录状态的历史变化，但如果直接修改原状态，历史记录里的旧状态值已经被篡改，你无法回溯到真正的原始状态，排查问题时根本搞不清状态是何时被修改的。

• 并发渲染下的不可预测行为
  React的并发模式允许在渲染过程中中断、暂停或优先级调整更新。如果在并发渲染过程中直接修改原状态，会导致状态处于“半修改”的不一致状态，当React恢复渲染时，基于被篡改的状态继续处理，很可能引发难以复现的渲染错误。

• 违反最佳实践，降低代码可维护性
  React社区一直强调状态不可变性是核心原则，这种突变式的写法会让团队其他成员困惑——阅读代码时无法直观判断状态的更新逻辑，后续维护时很容易不小心引入更多的状态突变bug。

哪怕不用定时器，这种写法也存在很多潜在风险。正确的做法是遵循不可变性原则，克隆到目标层级，或者使用Immer这类库来简化嵌套对象的更新操作。

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