React里状态更新不生效，最典型的原因就是对对象或数组做了原地修改。类组件中直接调用this.state.list.push(newItem)，随后执行this.setState({list: this.state.list})，页面往往不会出现任何变化；函数组件里写setList(list => { list.push(newItem); return list; })，有时也会得到相同的结果。要解决这个问题，必须先理解React判断状态是否变化的底层逻辑：只有当传入的新状态与旧状态的引用不同，组件才会重新渲染。

为什么直接修改状态不会触发更新

React的类组件setState和函数组件useState在内部处理更新时，都会使用Object.is对前后状态做浅比较。所谓浅比较，就是比较两边的值是否严格相等，对于对象和数组这类引用类型，比较的其实是内存地址。如果你在原有数组上执行push、splice，或者直接给原对象的属性重新赋值，内存地址并没有发生改变，React就会认为状态没有变化，从而跳过本次更新。

这不是React特有的局限，而是不可变数据思想在状态管理中的体现。不可变更新要求每次修改都产生一个全新的对象或数组，把新引用交给setState或setXXX。这样做的好处是React可以快速判断是否需要渲染，配合React.memo、useMemo等优化手段时也能得到更准确的结果。

// 错误示范：直接修改数组
this.state.items.push(newItem);
this.setState({ items: this.state.items });
// 错误示范：直接修改对象
setUser(user => {
  user.name = 'Tom';
  return user;
});

上面的代码中，数组或对象仍然是同一个引用，React在进行浅比较时会认为状态没有发生变化，组件因此不更新。即便某些情况下因为父组件更新导致子组件重新渲染，这种写法也会带来不可预测的状态污染，埋下隐患。

对象状态：如何正确返回新对象

正确更新对象的思路很直接：每次修改都基于旧对象创建一个新对象。最常用的方式就是使用展开运算符...，它可以浅拷贝对象的所有自有可枚举属性。比如只想修改user对象的name字段，可以这样写：

// 类组件正确更新对象
this.setState({
  user: {
    ...this.state.user,
    name: 'Tom'
  }
});
// 函数组件正确更新对象
setUser(prev => ({
  ...prev,
  name: 'Tom'
}));

展开运算符会创建一个新对象，并把旧对象的第一层属性复制进去，然后再覆盖需要修改的字段。由于新对象的引用与旧对象不同，React能够识别到状态已经改变，从而触发重新渲染。如果一次需要修改多个属性，可以继续在展开后面追加字段，例如同时修改name和age。

需要注意一个关键点：展开运算符只做浅拷贝，也就是只复制第一层属性。如果user对象内部还嵌套了一个profile对象，那么{...prev.user}得到的profile仍然指向原来的引用。在这种场景下，仅仅创建一层新对象是不够的，必须对嵌套结构逐层处理，这一点会在后面详细说明。

数组状态：用不可变方式增删改

数组的不可变更新比对象稍微复杂一些，因为它有增、删、改、插入等多种操作，但核心原则保持不变：永远返回一个新数组。对于添加元素，可以使用concat方法或者展开运算符；对于删除元素，推荐使用filter；对于修改某一条数据，推荐使用map。

// 添加元素：concat或展开
this.setState({
  items: this.state.items.concat(newItem)
});
setItems(prev => [...prev, newItem]);
// 删除元素：filter
setItems(prev => prev.filter(item => item.id !== targetId));
// 修改其中一条：map
setItems(prev => prev.map(item =>
  item.id === targetId ? { ...item, status: 'done' } : item
));

filter会返回一个过滤后的新数组，不会影响原数组；map同样会返回一个新数组，如果某一项需要修改，就在回调中返回一个新对象，否则返回原始项。这样既保持了不可变性，又能够让React正确识别变化。相比之下，push、pop、splice、sort等方法都会原地修改数组，应尽量避免直接在状态上使用。

如果确实需要做排序，可以先拷贝一份数组再调用sort，例如：

// 先复制，再排序，避免原地修改
const sorted = [...items].sort((a, b) => a.order - b.order);
setItems(sorted);

这样sort作用在新的数组副本上，原状态数组不会被污染，同时新数组的引用发生变化，组件能够正常更新。

嵌套状态与浅拷贝的坑

嵌套状态是最容易写出问题的地方。假设状态结构如下：

const [form, setForm] = useState({
  title: '文章标题',
  author: {
    name: 'Tom',
    profile: {
      city: 'Shanghai'
    }
  }
});

如果只想修改city字段，只做一层展开是不够的。下面的写法虽然创建了新的form对象，但author仍然指向旧对象，直接修改author.profile.city会污染旧状态：

// 风险写法：只复制了第一层
setForm(prev => {
  const newForm = { ...prev };
  newForm.author.profile.city = 'Beijing';
  return newForm;
});

这种写法中，newForm虽然是一个新对象，但author和profile都是旧引用。局部修改可能导致组件不会按预期更新，或者造成旧状态被意外修改。正确做法是沿着嵌套路径逐层创建新对象：

// 正确：逐层展开
setForm(prev => ({
  ...prev,
  author: {
    ...prev.author,
    profile: {
      ...prev.author.profile,
      city: 'Beijing'
    }
  }
}));

可以看到，嵌套层级越深，代码就越冗长。为了改善可读性，可以借助immer这类不可变数据库。它允许你以“可变”的方式编写代码，内部通过Proxy跟踪修改，最终生成一个全新的不可变状态。

使用immer简化不可变更新

当状态嵌套层级较多时，手写逐层展开不仅繁琐，而且容易漏掉某一层。此时可以引入immer，它的produce函数接收原状态和一个修改回调，在回调里可以直接修改草稿对象，immer会负责生成新引用。

import { produce } from 'immer';
// 使用immer直接修改草稿
setForm(prev => produce(prev, draft => {
  draft.author.profile.city = 'Beijing';
}));

这段代码看起来像是在直接修改状态，实际上draft是一个代理对象，所有修改都会被记录下来，最终返回一个新的form对象。这样既保证了不可变性，又让代码非常直观。对于大型表单、复杂列表等场景，immer可以显著降低维护成本。

当然，如果项目规模较小，不希望引入额外依赖，也可以把逐层展开封装成工具函数，或者在状态设计阶段尽量避免过深的嵌套结构。把状态拆分成更细粒度的useState，或者使用useReducer管理复杂状态，也是不错的替代方案。

解决setState不生效问题的关键，始终是记住一个原则：不要原地修改对象或数组。无论使用类组件的setState，还是函数组件的useState，都必须返回一个新引用。对象用展开运算符，数组用concat、filter、map，嵌套结构注意逐层复制。掌握了这些要点，React状态更新就会变得稳定而可预测。