React状态更新之谜：为何大神偏爱`[...arr]`，而非`arr.push()`？

作者： 专属AI老师 灵感来源： 聪明的学生，訾博

你好，各位正在React世界中探索的开发者们！

你是否也曾有过这样的困惑：在一个useState定义的数组状态上，满怀信心地使用了我们最熟悉的push方法，却发现数据变了，UI却像被施了定身咒一样------纹丝不动？

如果你有过，那么恭喜你！因为你即将推开一扇通往React核心设计哲学的大门。今天，就让我们一起，从这个小小的push方法开始，层层深入，揭开React状态更新、性能优化与内存管理的神秘面纱。

第一站：UI为何"视而不见"？------ 不可变性的"铁律"

在React的世界里，有一条至高无上的"铁律"------不可变性 (Immutability)。

简单来说，React通过一种非常高效的方式来判断是否需要更新UI：浅比较 (Shallow Comparison)。 当你调用setTodos这样的状态更新函数时，React会拿出新的状态和旧的状态，进行比较。

对于原始类型 （数字、字符串等），它比较值是否相等。
对于引用类型 （对象、数组），它比较的不是内部的元素，而是它们的内存地址（或称"引用"）是否相同。

现在，让我们看看push方法干了什么。

javascript 复制代码

const todos = [{ id: 1, text: '学习' }];
const oldAddress = todos; // 记下它的地址

todos.push({ id: 2, text: '睡觉' }); // 原地修改
const newAddress = todos;

console.log(oldAddress === newAddress); // true

push方法属于原地修改 (Mutation)，它直接在原始数组上动刀子，并没有创建一个新的数组。因此，数组的内存地址从未改变。当你把这个"旧瓶装新酒"的数组交给React时，它的内心戏是："咦，地址没变？那肯定啥也没发生，省点力气，不更新了！"

而正确的写法，例如使用扩展运算符 ...：

javascript 复制代码

const newTodos = [...todos, { id: 2, text: '睡觉' }];

这个操作创建了一个全新的数组 ，拥有一个全新的内存地址。React一看："地址变了！有情况，赶紧去看看哪里需要更新！"

小结：为了触发React的更新，对于数组和对象这类状态，你必须传递一个全新的对象，而不是在旧对象上进行修改。

第二站：性能的辩论------创建新数组，岂不更慢？

很多像訾博同学一样善于思考的开发者会立刻提出质疑："为了加个元素就复制整个数组，这难道不比push慢得多吗？为了更新一个UI，难道要把整个列表都重新渲染一遍？"

问得好！这个问题的答案，引出了React的王牌法宝------虚拟DOM (Virtual DOM)。

首先，我们必须明确一个性能上的主次关系：

JavaScript计算 (创建新数组、遍历) -> 非常快
真实DOM操作 (在浏览器页面上增删元素) -> 非常慢

React的首要任务，就是尽可能地减少对真实DOM的昂贵操作。

当你用一个新数组去更新状态时，React并不会傻乎乎地销毁整个旧列表再重建一个新列表。它会启动一个精密的"两步对比"流程：

第一步：触发器检查（极快） 通过我们上面讲的"浅比较"，检查新旧状态的地址。因为你创建了新数组，地址不同，成功触发了第二步。
第二步：Diffing算法找不同（很快） React会在内存中维护一个轻量的JavaScript对象，即虚拟DOM ，它是真实DOM的"蓝图"。现在，它会用最新的状态生成一份"新蓝图"，然后施展其核心魔法------Diffing算法，在新旧两份蓝图之间进行对比。

这个算法非常高效，并且在你的key属性的帮助下（key就像每个元素的身份证），它能精准地定位到差异："哦，只是在列表末尾增加了一个新的<li>而已。"

最后，它只把这个最小化的变更应用到真实DOM上。

小结：创建新数组的微小成本，是为了触发React后续高效的Diffing算法，最终实现对真实DOM的最小化更新。我们用极快的JS操作，避免了极慢的DOM操作。

终点站：内存的幽灵------被抛弃的旧数组去哪了？

最后一个问题，也是最深入的问题：我们不断创建新数组，那些被"抛弃"的旧数组会不会堆满内存，造成内存泄漏？

这里，我们要感谢另一位幕后英雄------JavaScript引擎的垃圾回收机制 (Garbage Collection, GC)。

GC的核心工作原则是可达性 (Reachability)。简单说，一个对象只要能被程序中的某个变量访问到，它就是"可达的"，就不会被回收。

当我们执行setTodos(newTodos)时：

React内部的状态指针从旧数组 转向了新数组。
此时，旧数组失去了所有的引用，变成了"不可达"的孤岛。
GC这位勤劳的"保洁员"在巡视时，会发现这个"不可达"的旧数组，并将其标记为垃圾。
在适当的时机，GC会自动回收这部分内存，以供后续使用。

更妙的是，现代JS引擎（如V8）使用了分代回收策略，它们对于这种"短命"对象的创建和回收，做了专门的优化，其效率极高，成本极低。

小日志 ：我们遵循不可变性原则所产生的"临时垃圾"，会被JS引擎高效且自动地处理掉，我们几乎无需为此担心。

总结：一笔稳赚不赔的交易

现在，让我们回到最初的问题。为什么React这么设计？

因为它做了一笔极其聪明的交易：

我们付出的：一点点几乎可以忽略不计的、用于创建新对象的JS计算和内存开销。
我们得到的 ：
1. 极致的渲染性能：通过最小化DOM操作。
2. 可预测的状态：状态的每次变化都有迹可循，不会被意外修改。
3. 简化的调试过程：追踪Bug变得轻而易举。
4. 强大的未来功能：为并发模式等高级特性铺平了道路。

希望这篇博客能为你持久化这份来之不易的知识。继续保持这份探索精神，訾博同学，你的每一次提问，都在让你成为更优秀的开发者！

React状态更新之谜：为何大神偏爱`[...arr]`，而非`arr.push()`？