JS数组头部追加用unshift还是splice？

一、快速上手：两种语法的写法与基础行为

假设我们正在开发一个即时聊天窗口，现有消息数组中存放着旧消息。当 WebSocket 收到新消息时，需要将其置于列表最前端展示给用户。

1. 使用 unshift() 追加

unshift() 是 Array.prototype 专门用于在数组开头添加一个或多个元素的方法。它会直接修改原数组，并将新元素放置在索引 0 处：

// 原始消息列表
const messages = ['消息B: 你好', '消息C: 收到'];

// 向头部追加一条新消息
const newLength = messages.unshift('消息A: 刚发送');

console.log(messages); 
// 示例输出: ['消息A: 刚发送', '消息B: 你好', '消息C: 收到']

console.log(newLength); 
// 示例输出: 3 (返回新数组的长度)

2. 使用 splice() 在索引 0 处插入

splice() 是一个多功能方法，用于在数组的任意指定索引处删除现有元素并/或添加新元素。当我们将起始索引设为 0、删除元素个数设为 0 时，它同样能达到在开头插入的效果：

const messages = ['消息B: 你好', '消息C: 收到'];

// 从索引 0 开始，删除 0 个元素，随后插入新消息
const removed = messages.splice(0, 0, '消息A: 刚发送');

console.log(messages); 
// 示例输出: ['消息A: 刚发送', '消息B: 你好', '消息C: 收到']

console.log(removed); 
// 示例输出: [] (返回包含被删除元素的数组，此处未删除任何元素，因此是空数组)

二、关键行为差异：返回值与批量插入陷阱

虽然两者都能将项塞入头部，但它们的返回值完全不同，且在批量插入多个项时存在容易混淆的使用细节。

1. 返回值完全不同（最易踩坑点）

初学者常常误以为数组修改方法会返回“修改后的原数组”。事实上：

• unshift() 返回的是数值（Number）：表示插入完成后的新数组 length。如果写出 const updated = list.unshift(item)，updated 得到的将是一个数字（如 3），若后续继续当作数组调用 .map() 会直接触发 TypeError: updated.map is not a function。
• splice() 返回的是数组（Array）：它返回包含所有“被移除元素”的列表。当我们在头部仅做追加时，没有删除任何项，因此它始终返回一个空数组 []。如果误将其当作新数组传递给视图，页面渲染出的就是空白。

2. 批量追加多个元素时的顺序差异

当需要向头部追加多个数据（如 'Alpha' 和 'Beta'）时，调用方式决定了元素的前后排列：

// 场景 1：在 unshift 中同时传入多个参数
const list1 = ['Gamma'];
list1.unshift('Alpha', 'Beta');
console.log(list1); 
// 示例输出: ['Alpha', 'Beta', 'Gamma'] (传入参数顺序得以完整保留)

// 场景 2：连续多次调用 unshift
const list2 = ['Gamma'];
list2.unshift('Alpha');
list2.unshift('Beta');
console.log(list2); 
// 示例输出: ['Beta', 'Alpha', 'Gamma'] (后调用的 Beta 会被顶到最前面！)

// 场景 3：使用 splice 传入多个参数
const list3 = ['Gamma'];
list3.splice(0, 0, 'Alpha', 'Beta');
console.log(list3); 
// 示例输出: ['Alpha', 'Beta', 'Gamma'] (与场景 1 一致)

如果在循环中单条处理并逐个推入头部，必须留意元素倒序的问题。如果要保持原本的序列，应当在一次调用中解构展开（如 list.unshift(...newItems)）或先反转再处理。

三、底层原理与性能考量：头部追加为什么总是 O(n)？

很多开发者会好奇：底层实现上，unshift 会不会比 splice 更快？或者反过来，通用底层的 splice 经过了更多微优化？

1. 内存连续存储与索引移动机制

在 JavaScript 引擎（如 Google V8）中，常规数组多以连续内存缓冲区的形式存储（即快速元素 Fast Elements）。

当调用 push() 向末尾追加元素时，如果容量尚未超出预分配边界，引擎只需要将新值写入紧邻的下一个内存槽位并增加 length，时间复杂度为 O(1)。

但在数组开头插入元素时，情况完全不同：

1. 索引 0 的位置已被旧元素占据。
2. 为了给新元素腾出空间，引擎必须遍历现有数组的所有元素，将每个元素向右整体平移 1 个单位（原本索引 0 -> 1，1 -> 2，……，n-1 -> n）。
3. 平移完成后，将新元素写入空出来的索引 0，并更新数组长度。

这意味着：无论是调用 unshift() 还是 splice(0, 0, ...)，底层都必须完整执行一次向右平移全部现有元素的内存位移动作。在包含 $n$ 个元素的数组中，两者的时间复杂度都是不可避免的 O(n)。

2. 实测性能对比与建议

在不同规模的数组基准测试中（100 到 100,000 个元素）：

• 在数据量较小（如几百条以内的常见业务数据）时，两种方法的执行耗时通常在 0.001 毫秒以下，性能开销完全可以忽略。
• 在数据量超过数万条时，两者的性能瓶颈均在于内存块平移（memmove 调用），两者的耗时差距极小（在毫秒级波动范围内）。

四、现代实践：何时两者都不用？

在 React、Vue 3 或 Redux 等现代前端框架中，我们常常需要遵守状态不可变性（Immutability）原则。无论是 unshift() 还是 splice()，都会就地变异（Mutate）原数组，这会导致组件无法侦测到状态引用变化，从而导致界面不刷新。

1. 展开运算符（Spread Operator）—— 推荐做法

使用 ES6 展开运算符创建新数组，既语义直观，又天然支持不可变数据流：

// React 状态更新示例
const [todos, setTodos] = useState(['完成文档', '提交代码']);

// 向头部追加新待办（不修改旧 todos 引用）
setTodos(prev => ['晨会沟通', ...prev]);

2. ECMAScript 2023 新标准：toSpliced()

ECMAScript 2023 引入了 toSpliced() 方法。与 splice() 的区别在于：它不修改原数组，而是直接返回插入/删除后的全新数组拷贝：

const original = ['B', 'C'];
// 返回新数组，且保持 original 不变
const updated = original.toSpliced(0, 0, 'A');

console.log(original); // 示例输出: ['B', 'C'] (原数组毫发无损)
console.log(updated);  // 示例输出: ['A', 'B', 'C'] (返回新数组)

五、最终选型决策与总结

面对“头部追加”的需求，可以根据下方的决策树快速确定最佳实现方案：

总结：面对“JS 数组头部追加用 unshift 还是 splice”的问题，答案很明确——用 unshift。在现代 JavaScript 中，代码的可读性与意图表达远远先于微小的语法偏好；而需要不可变更新时，则果断转向展开运算符或 toSpliced。