为何JavaScript中shift比unshift慢这么多？性能差异探究

你观察到的shift与unshift的巨大性能差异，核心源于JavaScript引擎（以V8为例）对连续数组操作的优化策略差异，而非单纯的“首尾操作”逻辑区别。

底层原理差异 #

JavaScript数组在V8引擎中分为两种存储模式：

• 快数组：当元素类型一致、数量较多时，采用连续内存块存储，类似传统数组。
• 慢数组：元素类型混杂时，采用哈希表存储，性能较低。

你的测试中数组都是数字，属于快数组，但引擎对unshift和shift的优化逻辑完全不同：

1. push/pop的无差异逻辑：两者都是操作数组末尾，仅需修改数组长度指针，无需移动其他元素，因此性能接近（你的测试中pop仅比push慢不到2倍，属于正常的指针操作开销）。
2. unshift的批量优化：当你连续调用unshift时，V8引擎会预判你的操作模式，提前计算所需的总内存空间，将元素一次性复制到合适的位置，避免每次unshift都移动全部现有元素。比如你循环10万次unshift，引擎不会每次都把已有元素往后挪一位，而是直接预分配足够的头部空间，批量完成元素插入。
3. shift的无优化空间：shift是每次删除数组第一个元素，必须将剩余所有元素往前移动一位——而且引擎无法预判你会连续执行10万次shift，因此每次操作都要实时移动当前数组的所有剩余元素。随着数组长度从10万递减到0，总移动元素次数是(99999 + 0) * 100000 / 2 = 5e9次，这直接导致了耗时的爆炸式增长。

你的测试数据验证 #

从你的测试结果可以直观看到：

• push/pop耗时极低，仅需数毫秒；
• unshift因引擎批量优化，耗时控制在1秒内；
• shift因每次都要移动大量元素，耗时达到14秒，是unshift的14倍。

高效队列的替代实现 #

如果需要构建高性能队列，绝对不要用原生数组的shift方法，推荐使用基于偏移量的模拟队列，通过维护一个起始指针避免元素移动：

class FastQueue {
  constructor() {
    this._array = [];
    this._startIndex = 0;
  }

  enqueue(item) {
    this._array.push(item);
  }

  dequeue() {
    if (this.isEmpty()) return undefined;
    const item = this._array[this._startIndex];
    this._startIndex++;
    
    // 当起始指针超过数组一半长度时，裁剪数组释放内存（可选）
    if (this._startIndex > this._array.length / 2) {
      this._array = this._array.slice(this._startIndex);
      this._startIndex = 0;
    }
    return item;
  }

  isEmpty() {
    return this._startIndex >= this._array.length;
  }

  get size() {
    return this._array.length - this._startIndex;
  }
}

这种实现的enqueue和dequeue操作均为**均摊O(1)**时间复杂度，性能与push/pop持平。

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