不必使用 ... 扩展运算符，这三个场景下性能极差

最新推荐文章于 2025-11-28 09:44:01 发布

原创最新推荐文章于 2025-11-28 09:44:01 发布 · 349 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#前端 #javascript #开发语言

绝大多数使用扩展运算符的地方都不会构成性能问题。但是，当需要处理海量数据、高频更新或性能敏感的核心逻辑时，考虑下 ... 是否正在悄悄地拖慢我们的程序。

扩展运算符无疑是我们 JavaScript 开发者最喜爱的语法糖之一。

其代码优雅、简洁，可读性极高，并且完美契合了函数式编程和不可变性的思想。

然而，在某些特定场景下，扩展运算符可能会导致严重的性能瓶颈，甚至拖垮我们的应用。

... 的本质

对于数组或对象，扩展运算符会：

创建一个新的空数组或空对象
遍历原始数据结构的所有可枚举属性（对于对象）或所有值（对于数组）
将遍历到的每一个值逐一复制到这个新的数据结构中

关键点在于：创建新对象/数组和遍历并复制。当数据量很小的时候，这点开销微不足道，但当数据量变大或操作频率变高时，问题就暴露了。

场景一：操作大型数组

这是最常见也最容易被忽视的性能陷阱，假设你有一个包含数百万条记录的数组（例如，从后端获取的海量数据），你只是想在末尾添加一个新元素。

// 性能不佳的写法
const hugeArray = Array(1_000_000).fill(0);
const newItem = 1;

const newArray = [...hugeArray, newItem]; // 🚩 问题所在

为了添加 newItem，扩展运算符创建了一个全新的数组 newArray，然后把 hugeArray 中的一百万个元素全部循环复制了一遍，最后才把 newItem 放进去。这个操作的时间复杂度是 O(n)，其中 n 是数组的长度。每次添加，都意味着一次完整的大规模内存分配和数据拷贝。

如果你的场景允许直接修改原数组（即不需要保持不可变性），使用 push() 方法是最高效的。

push() 的时间复杂度是 O(1)（摊销分析），它直接在数组的末尾添加元素，几乎没有额外开销。两者性能相差成百上千倍。

场景二：在循环中频繁更新状态

这个场景在 Redux 的 Reducer 或其他状态管理模式中尤为常见，开发者为了保持状态的不可变性，在循环中反复使用扩展运算符。

假设我们需要根据一个 ID 列表来构建一个对象映射（Map）。

const ids = ['id_1', 'id_2', /* ...成千上万个ID */];

// 性能不佳的写法
const userMap = ids.reduce((acc, id) => {
  // 每次循环都创建一个新对象，并复制所有已有属性
  return {
    ...acc, // 🚩 问题所在
    [id]: { name: `User ${id}` }
  };
}, {});

这个 reduce 操作看起来很函数式，很“正确”，但性能却是一场灾难。

第一次循环，acc 是 {}，返回 { id_1: ... }。
第二次循环，acc 是 { id_1: ... }，为了加入 id_2，它会创建一个新对象，复制 id_1 的所有内容，再添加 id_2。
第三次循环，它会创建一个新对象，复制 id_1 和 id_2 的内容，再添加 id_3。
…
第 n 次循环，它会复制 n-1 个已有属性。

这个过程的总操作次数大致是 1 + 2 + … + (n-1)，时间复杂度高达 O(n²)。同时，它在内存中创建了大量的临时对象，给垃圾回收（GC）带来了巨大压力。

在循环内部，使用一个可变对象进行操作，循环结束后再返回最终结果。这并不会破坏外部的不可变性。

或者使用更直观的 for 循环

场景三：将类数组对象（Array-like Object）转换为数组

在处理 arguments、NodeList、HTMLCollection 等类数组对象时，用扩展运算符转换成真数组非常方便。

function processArgs() {
  const args = [...arguments]; // 看起来很简洁
  // ...
}

const elements = document.querySelectorAll('div');
const elementArray = [...elements]; // 同样简洁

虽然这种方式在大多数情况下性能尚可，但 JavaScript 引擎对 Array.from() 做了专门的优化，它不仅性能更好，语义也更清晰：明确表示“从一个类数组/可迭代对象创建一个新数组”。