shift()和unshift()比push/pop慢，因其需O(n)时间重新索引所有后续元素并可能重分配缓冲区，而push/pop仅操作末尾、平均O(1)；十万项数组中shift比pop慢百倍以上。
JavaScript数组的shift()和unshift()方法执行效率较低，主要因为它们需要重新索引整个数组，时间复杂度为 O(n)。
为什么shift和unshift比push/pop慢？
JavaScript数组在内存中是连续存储的（逻辑上），当调用shift()删除首项或unshift()插入首项时，引擎必须：
- 移动所有后续元素的索引位置（如原索引1→0、2→1……）
- 更新数组的
length属性 - 可能触发内部数组缓冲区的重分配（尤其在大数组或频繁操作时）
相比之下，push()和pop()只操作末尾，无需位移其他元素，平均时间复杂度为 O(1)。
实际性能差异有多大？
差异随数组长度线性增长。例如对一个含10万项的数组：
立即学习“Java免费学习笔记（深入）”；
-
shift()通常耗时 0.1–1ms（取决于引擎和硬件） -
pop()通常低于 0.001ms - 重复调用
shift()遍历数组（如模拟队列）可能比pop()慢百倍以上
Chrome V8 和 Firefox SpiderMonkey 均未对首部操作做特殊优化，底层仍基于索引平移。
有什么更高效的替代方案？
若需高频首尾操作，避免直接使用原生数组：
- 用
Array.prototype.push()+Array.prototype.pop()反向处理：把“头部”当作“尾部”，逻辑翻转 - 使用
Deque类（如petkaantonov/deque）或自己实现双端队列（基于两个数组或链表结构） - 对固定场景，改用
TypedArray配合游标（如Uint32Array+head/tail索引），绕过动态索引开销
什么情况下可以放心用shift/unshift？
小数组（
- 配置列表、临时参数拼接、一次性数据预处理
- 代码可读性优先且性能非瓶颈时，不必过度优化
- 注意：某些打包工具（如Webpack）的模块依赖解析曾因大量
shift()拖慢构建，属例外场景
不复杂但容易忽略——关键看数据规模与调用频率。
