React嵌套状态更新：为何要在每层状态使用扩展运算符？

核心问题拆解 #

你提到的两种更新方式都能触发当前组件重新渲染，但前者是符合React状态不可变性原则的标准做法，后者存在隐藏的风险与隐患，以下是具体分析：

1. React状态的不可变性核心原则 #

React的状态设计基于不可变数据范式：永远不要直接修改原状态对象，必须返回全新的状态引用。这是因为React依赖状态引用的变化来判断是否需要触发组件重渲染。

• 第一种方式：

setState(current => ({
  ...current,
  profile: {
    ...current.profile,
    bio: newBio
  }
}));

这里不仅顶层状态是全新对象，嵌套的profile也生成了新的引用，完全遵循不可变性要求。

• 第二种方式：

setState(current => {
  let newState = { ...current };
  newState.profile.bio = newBio;
  return newState;
});

虽然顶层状态是新引用，但newState.profile和原current.profile指向同一个对象——你直接修改了原状态中的嵌套对象，违反了不可变性原则。

2. 隐藏的风险点 #

（1）与React.memo/useMemo等优化逻辑冲突 #

函数组件中常用React.memo缓存子组件，它默认通过浅比较判断是否重渲染。如果子组件接收的profile是同一个引用（即使内部属性已修改），React.memo会判定属性无变化，跳过子组件渲染，导致子组件显示旧数据。

比如有这样的子组件：

const Profile = React.memo(({ profile }) => {
  return <div>{profile.bio}</div>;
});

用第二种方式更新时，profile引用未变，Profile组件不会重渲染，用户看不到更新后的bio内容。

（2）调试与状态回溯失效 #

React DevTools的时间旅行调试功能依赖状态的不可变性——如果直接修改原状态，你无法回溯到之前的状态快照，调试时会无法追踪状态的变更轨迹。

（3）引发意外副作用 #

如果其他逻辑（比如全局状态、缓存）也引用了这个profile对象，直接修改它会导致这些地方的数据意外变更，引发难以排查的bug。

3. 为什么第二种方式看起来"生效"？ #

因为顶层状态的引用发生了变化，当前组件会触发重渲染，读取到修改后的profile.bio值。但这只是"表面生效"，一旦涉及子组件缓存、状态快照或其他依赖该嵌套对象的逻辑，就会暴露问题。

总结 #

逐层创建新对象的核心目的是维护状态的不可变性，这是React状态管理的基础原则。它能确保状态变化可预测、可追踪，避免子组件缓存失效、调试困难、意外副作用等问题。虽然第二种方式写法更简便，但埋下了长期维护的隐患，并不推荐。

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