React更新useState管理的数组时必须每次全量复制吗？

全量复制/遍历数组的开销是不是不可避免？ #

首先要明确两个核心事实：

• React 对引用类型状态的更新检测依赖引用变化：如果你直接修改原数组（比如用splice改某一项、push加新项），数组的内存地址没有变，React会认为状态没有变化，不会触发重渲染，因此你必须返回一个新的数组引用，这是不可变状态的基本要求。
• 你目前用map更新数组的写法，并没有深拷贝所有数组元素：新数组只是一个新的数组容器，不需要更新的元素都是直接返回原引用，本质是一次浅拷贝，开销远低于很多人的想象。现代JS引擎处理浅拷贝的速度非常快，10万长度的数组浅遍历+创建新数组，耗时通常在1ms以内，远低于浏览器单帧16ms的卡顿阈值，99%的业务场景下完全感知不到开销。

如果你的场景真的存在百万级以上的数组元素，全量O(n)遍历确实会产生可感知的开销，这部分开销不是不可避免的，可以通过后续的优化方案规避。

concat和扩展运算符的性能对比 #

items.concat(newItem)和[...items, newItem]的实现逻辑几乎完全一致：都是新建一个空数组，按顺序填入原数组的所有元素引用，再追加新元素。在2018年之后的现代JS引擎中，两者的性能差异已经被引擎优化完全拉平，不存在谁明显更快的说法，选择符合自己代码习惯的写法即可，没必要在这个点上做无效优化。

可落地的性能优化方案 #

所有优化的前提都是先测量再优化：优先用React DevTools Profiler、浏览器Performance面板定位实际的性能瓶颈，不要为了极端场景提前增加代码复杂度。

• 拆分大状态：如果数组长度确实很大，可以按分页、分组维度把大数组拆成多个独立的小state，更新单条数据时只需要操作对应分组的小数组，从根源上降低单次更新需要遍历的元素量。
• 降低查找开销：如果更新操作的主要耗时在遍历查找对应id的元素，可以用useRef维护一个id -> 数组索引的Map映射表，增删元素时同步更新映射表，更新时可以O(1)直接拿到目标元素的索引，省去全量遍历的开销。注意这个映射表不需要触发重渲染，存在useRef中即可，不需要放到state里。
• 使用结构共享的不可变工具：可以用Immer这类库处理不可变更新，它内部基于写时复制逻辑实现结构共享，修改单个数组项时只会新建路径上的必要节点，其余节点全部复用原引用，同时可以让你用更直观的可变语法写更新逻辑，减少出错概率：

  import { produce } from 'immer';
  const [items, setItems] = useState([]);
  
  // 更新单条
  const updateItem = (updatedItem) => {
    setItems(produce(items, draft => {
      const targetIndex = idIndexMap.current.get(updatedItem.id);
      if (targetIndex !== undefined) draft[targetIndex] = updatedItem;
    }))
  }
  
  // 新增条目
  const addItem = (newItem) => {
    setItems(produce(items, draft => {
      draft.push(newItem);
    }))
  }
  

• 配合虚拟滚动处理超长列表：如果是需要渲染10万条以上数据的长列表场景，优先接入虚拟滚动方案（比如react-window），只渲染视口内的少量DOM元素。这种场景下数组浅拷贝的开销和DOM渲染的开销比起来几乎可以忽略，虚拟滚动带来的性能提升远大于抠数组复制的收益。

避坑提醒 #

不要为了省去浅拷贝数组的开销直接修改原数组，这种写法会导致状态更新不触发重渲染、闭包状态过期等一系列难以排查的问题，收益极低，风险极高。

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