JavaScript随机枢轴快速排序：原理、实现与性能实测

如果你在面试里被要求手写快速排序，十有八九会碰到这样一个追问：为什么枢轴要随机选？我去年做项目时需要处理一个十万量级的数据排序场景，顺手把网上能找到的快排方案全翻了一遍，固定枢轴、随机枢轴、三路切分、迭代版本都实测了个遍。这篇博文就是那次折腾的完整记录，主题就是用 JavaScript 实现带随机枢轴的快速排序（QuickSort with Random Pivoting），把算法背后的概率逻辑、复杂度推导、工程化优化和实际避坑一次说清。适合正在准备算法面试、想在浏览器或 Node 环境里手写排序、或者只是想把快排原理彻底弄明白的同学。代码不长，但里面的门道比想象中多。

1. 快速排序的基本逻辑与随机枢轴的起源

1.1 分而治之：快排的三步骨架

快速排序是典型的分治算法，核心思想可以浓缩成三步：先从数组里选一个元素作为“枢轴”（pivot），然后把数组里剩下的元素分成两组，小于枢轴的放左边，大于枢轴的放右边，最后对左右两个子数组递归重复这个过程。整个过程做完之后，数组天然就是有序的。

用生活里的场景类比就是整理一摞试卷：先抽出一张当基准线，把分数低于它的丢左边、高于它的丢右边，然后对左右两堆继续做同样的事。注意，这个过程中我们并没有真正“排序”试卷，只是不断划分区间，划分到最后每个堆里只剩一张纸，顺序自然就出来了。快排的高明之处就在这里，它牺牲一部分稳定性，换来了极高的平均性能和极低的内存开销。

我在项目里选择快排而不是归并排序，主要两个原因。第一，快排可以原地工作，不需要额外的数组空间，对十万量级的数据来说，内存占用差别很可观；第二，在绝大多数真实数据分布下，快排的常数因子比归并排序更小，跑得更快。当然，快排有一个绕不过去的软肋，就是枢轴选得不好时性能会断崖式下跌，这就引出了随机枢轴存在的意义。

1.2 固定枢轴为什么会被“有序数组”打败

最直观的快排实现是固定取数组的第一个元素或者最后一个元素当枢轴。看起来没什么问题，但只要你输入一个已经排好序的数组，灾难就来了。假设数组是 [1, 2, 3, 4, 5, 6, 7, 8, 9]，第一次分区时枢轴是 1，比 1 小的元素一个都没有，左子数组为空，右子数组是 [2, 3, 4, 5, 6, 7, 8, 9]。第二次分区又遇到同样的情况，枢轴是 2，左边依旧为空。每次递归只能消掉一个元素，递归深度直接拉满到 n 层，时间复杂度退化成了 O(n²)，这跟冒泡排序还有什么区别。

真实项目里遇到完全有序的数据太常见了，比如后端接口返回的列表本身已经按某个字段排过序，前端又要按另一个字段重新排序。这种输入对固定枢轴快排来说就是一场灾难。所以聪明人想到一个办法：既然无法预判输入长什么样，那就让枢轴的位置变成随机的，让数据没法“精准打击”我们。

2. 随机枢轴到底解决了什么，代价又是什么

2.1 随机化破除了输入依赖

随机枢轴的做法非常简单，在每次分区前用 Math.random() 从一个区间里随机挑一个索引，拿这个位置上的元素当枢轴。这么做之后，算法的时间复杂度不再由输入数据的初始顺序决定，而是由随机数的运气决定。即使你运气差到极点，每次随机都挑到最大值或最小值，理论上仍然会出现 O(n²) 的最坏情况，但这种事情发生的概率低到可以忽略。

这里的关键在于“输入依赖”被打破了。固定枢轴的快排如果跑得慢，是因为输入数据恰好踩中了算法的死穴，这是确定的、可复现的、每次都会发生的；而随机枢轴的快排如果跑得慢，是因为随机数连续很多次都选到了边界值，这是概率事件，和输入数据没有任何关系。对一个排序模块来说，稳定的概率预期远比“赌输入数据是正常的”要可靠得多。

2.2 从“平均划分”理解期望复杂度 O(n log n)

很多文章直接告诉读者随机枢轴快排的期望复杂度是 O(n log n)，但没说为什么。我用直觉版本讲一遍。如果枢轴随机选择，那么它落在数组中间 50% 位置的概率是 50%，什么叫中间 50%？就是枢轴把数组划分成大致 1:3 或 3:1 的比例，而不是 1:n-1 这种极端比例。

只要划分比例不是极端失衡，递归树的每一层要处理的元素总数就是 n 个，划分比例再差，树的深度也保持在 O(log n) 级别。最坏情况是每次都划分成 1:n-1，这时候树深是 n。随机选择下，连续 n 次都选中边界元素的概率是 (2/n) 的 n 次方级别，n 到一万这个数字的时候，这个概率比连续中十次彩票头奖还低。所以实际操作中，随机枢轴快排的递归深度几乎不可能明显超过 4 倍 log₂n 的水平，期望复杂度就是 O(n log n)。

我做过一个简单对比，把随机选枢轴和不随机选枢轴在各类输入下的表现整理成了一张表：

2.3 随机化的工程代价几乎可以忽略

有人会担心每次分区都调一次 Math.random() 会不会拖慢速度，毕竟它本身也是一次函数调用和一次伪随机数计算。我的实测结论是：完全不用担心。快排在分区阶段要做的比较和交换次数是 O(n log n) 级别，而随机数生成的次数是 O(log n) 或 O(n) 级别，相比之下就是九牛一毛。

还有一个常见误解，觉得随机枢轴会破坏快速排序的稳定性。这里要先澄清，快速排序本身就不是稳定排序，跟枢轴怎么选没关系。如果你需要稳定排序，直接去用归并排序或者稳定版本的回溯快排，而不是纠结枢轴的选法。

3. 用 JavaScript 实现：随机枢轴快排的完整代码

3.1 分区函数是核心：先理解 Lomuto 风格的分区

网上快排实现五花八门，但大部分教学版本用的都是 Lomuto 分区。它的思路是：把枢轴先换到数组最右边，然后用一个指针 i 标记“小于枢轴区域”的边界，从头到尾遍历所有元素，遇到比枢轴小的就换到 i 的位置，同时 i 向前移动一位。遍历结束后，把枢轴从最右边换回 i 的位置，这样枢轴左边全是小于它的元素，右边全是大于等于它的元素。

Lomuto 分区的代码是最容易写对的，因为它只有一层 for 循环，没有太多边界条件。缺点是交换次数比另一种 Hoare 分区多一些，但对 JavaScript 场景来说，可读性和正确性比那一点点性能收益更重要。我项目里第一版就是 Lomuto，线上跑得很稳。

3.2 完整实现：递归版随机枢轴快排

直接上代码，这个版本是递归实现，逻辑清晰，适合学习和面试现场手写：

javascript复制function quickSort(arr, left = 0, right = arr.length - 1) {
  if (left >= right) {
    return;
  }

  // 随机挑选枢轴索引，注意是闭区间 [left, right]
  const pivotIndex = Math.floor(Math.random() * (right - left + 1)) + left;
  const pivot = arr[pivotIndex];

  // 把枢轴交换到最右边，方便分区遍历
  [arr[pivotIndex], arr[right]] = [arr[right], arr[pivotIndex]];

  let storeIndex = left;
  for (let i = left; i < right; i++) {
    if (arr[i] < pivot) {
      [arr[storeIndex], arr[i]] = [arr[i], arr[storeIndex]];
      storeIndex++;
    }
  }

  // 把枢轴放回正确位置
  [arr[storeIndex], arr[right]] = [arr[right], arr[storeIndex]];

  quickSort(arr, left, storeIndex - 1);
  quickSort(arr, storeIndex + 1, right);
  return arr;
}

这段代码最需要注意的就是随机索引的取法。Math.random() 返回的是 [0, 1) 之间的浮点数，所以乘的应该是 (right - left + 1)，意思是区间长度加一，然后向下取整再加 left。如果你写成 Math.floor(Math.random() * (right - left)) + left，那么最后一个索引 right 永远不会被选中，相当于每次随机都被迫排除一个位置，均匀性就破了。

3.3 这个实现有哪些边界值得背下来

我整理了手写这个版本时最容易出错的三个边界点，面试和实际编码都用得上。

第一个是递归终止条件。left >= right 时必须退出，不能只写 left === right。因为当某个子数组为空时，会出现 left > right 的情况，如果不处理就直接递归进去，下一轮函数访问 arr[right] 就可能越界。

第二个是 storeIndex 的初始值和更新时机。它是“下一个可交换位置”的指针，初始值一定是 left，不是 0。如果你写成 0，对整个数组排序没问题，但只要递归处理右子数组，就会把左侧已经排好的数据打乱。

第三个是分区完成后，左右子数组的边界。正确写法是 quickSort(arr, left, storeIndex - 1) 和 quickSort(arr, storeIndex + 1, right)，枢轴本身已经放在了正确位置，不需要再参与到后续递归里。

4. 性能实测：同等代码，不同输入的差别有多大

4.1 四种数据构造方式和测试方法

光说不练都是纸上谈兵。我在 Node v18 环境里做了一组对比测试，分别构造了四种输入：完全随机数组、已经升序排列的数组、已经逆序排列的数组、包含大量重复值的数组。每一种都分别跑固定首元素枢轴版本和随机枢轴版本，数组长度取 10 万，重复执行多次取中位数，避免单次噪声影响结论。

数据构造代码很简单，直接复用几个原生方法：

javascript复制const randomArr = Array.from({ length: 100000 }, () => Math.floor(Math.random() * 100000));
const sortedArr = Array.from({ length: 100000 }, (_, i) => i);
const reversedArr = Array.from({ length: 100000 }, (_, i) => 100000 - i);
const duplicateArr = Array.from({ length: 100000 }, () => Math.floor(Math.random() * 10));

测试时有一个大坑，就是每次排序前必须用 arr.slice(0) 拷贝一份，否则第一个算法跑完后原数组已经被打乱，第二个算法测的就是另一组数据了。我就是一开始忽略了这个问题，导致固定枢轴版本在“已排序数组”上的表现比理论值好很多，排查了半天才意识到数组引用被修改了。排障过程也挺有意思，后面会单独讲。

4.2 实测结果：固定枢轴与随机枢轴对比

以下是我本机跑出来的典型结果，单位是毫秒，数值在不同机器上会有浮动，但相对关系是稳定的：

看完这个表，你就明白为什么我一直强调随机枢轴是防御性的必要手段。在完全随机的数据上，两个版本性能几乎一样，随机枢轴甚至稍微慢了一点点，这是生成随机数的成本；但一旦碰到有序或逆序输入，固定枢轴直接退化到一秒以上，而随机枢轴依旧稳如泰山，几乎不受影响。

4.3 这轮测试里我发现的两个现象

第一个现象是，固定枢轴版本在大量重复值数组上表现其实还行，没有退化到 O(n²)。原因是重复值多的时候，arr[i] < pivot 的判定会让绝大多数相等元素不参与交换，分区的实际效果比理论分析要理想一些。不过这不代表可以高枕无忧，如果重复值是“均匀分布的有序段”，情况就会复杂得多。

第二个现象是，随机枢轴在随机数组上有时反而比固定枢轴快。一开始我以为是误差，多跑了几次发现是真实存在的。原因是固定首元素枢轴在随机数组上偶尔会遇到比较差的划分，产生更多递归调用；而随机枢轴虽然多了一次随机数生成，但划分质量更加平均，递归调用次数更少，整体反而更优。这也算是随机化策略的额外红利。

5. 从能用到好用：工程级优化手法盘点

5.1 大量重复数据怎么办：三路切分

纯随机枢轴版本在大部分场景下已经很能打了，但遇到大量重复元素的数组，比如按性别、评分、状态字段排序时，有一类专门的优化叫三路切分，也叫荷兰国旗问题解法。它的思路是分区时不仅分出“小于枢轴”和“大于枢轴”，还把“等于枢轴”的一整块单独隔离出来，后续递归时直接跳过这片区域。

代码如下：

javascript复制function quickSort3(arr, left = 0, right = arr.length - 1) {
  if (left >= right) return;

  const pivotIndex = Math.floor(Math.random() * (right - left + 1)) + left;
  const pivot = arr[pivotIndex];

  let lt = left;
  let gt = right;
  let i = left;

  while (i <= gt) {
    if (arr[i] < pivot) {
      [arr[i], arr[lt]] = [arr[lt], arr[i]];
      lt++;
      i++;
    } else if (arr[i] > pivot) {
      [arr[i], arr[gt]] = [arr[gt], arr[i]];
      gt--;
    } else {
      i++;
    }
  }

  quickSort3(arr, left, lt - 1);
  quickSort3(arr, gt + 1, right);
  return arr;
}

这段代码里的 lt 指向第一个等于枢轴的元素，gt 指向最后一个等于枢轴的元素。循环结束后，[left, lt-1] 是小于枢轴的部分，[lt, gt] 是等于枢轴的部分，[gt+1, right] 是大于枢轴的部分。实测下来，在重复值占比超过 50% 的数据上，三路切分比普通随机枢轴能快 3 到 5 倍。

5.2 小数组不递归，交给插入排序

很多工程师不知道，快速排序在小数组上并不占优势。原因在于递归调用和分区的常数因子比较大，当子数组长度只有二三十时，这些开销已经超过了插入排序所需的工作量。现代编程语言的排序库基本都做了这个优化，比如 V8 引擎里对小型数组会切换策略。

通用的做法是设置一个阈值，比如 16 或 32，当 right - left <= threshold 时直接调用插入排序：

javascript复制function insertionSort(arr, left, right) {
  for (let i = left + 1; i <= right; i++) {
    const current = arr[i];
    let j = i - 1;
    while (j >= left && arr[j] > current) {
      arr[j + 1] = arr[j];
      j--;
    }
    arr[j + 1] = current;
  }
}

function quickSortOptimized(arr, left = 0, right = arr.length - 1) {
  if (left >= right) return;
  if (right - left <= 16) {
    insertionSort(arr, left, right);
    return;
  }
  // 其余逻辑和前面完全一样
}

插入排序对小数组非常友好，它几乎不占用额外空间，在处理近乎有序的数据时更是快到离谱。实测数据里，加入这个优化后，快速排序在 10 万元素完全随机数组上的耗时又降了 10% 左右。

5.3 把递归改成显式栈，彻底控制栈深度

还有一个比较硬核的优化是把递归改写成显式栈。虽然随机枢轴让递归深度期望保持在 O(log n) 级别，但在某些极端情况下仍然可能出现栈溢出，尤其是在浏览器老版本或者递归深度受限的嵌入式环境里。改成显式栈之后，能彻底摆脱调用栈深度限制。

核心思路是用一个数组模拟栈，每次弹出待处理的区间，分区完成后把左右子区间压入栈中继续处理：

javascript复制function quickSortIterative(arr) {
  const stack = [[0, arr.length - 1]];

  while (stack.length) {
    const [left, right] = stack.pop();
    if (left >= right) continue;

    const pivotIndex = Math.floor(Math.random() * (right - left + 1)) + left;
    const pivot = arr[pivotIndex];

    [arr[pivotIndex], arr[right]] = [arr[right], arr[pivotIndex]];
    let storeIndex = left;

    for (let i = left; i < right; i++) {
      if (arr[i] < pivot) {
        [arr[storeIndex], arr[i]] = [arr[i], arr[storeIndex]];
        storeIndex++;
      }
    }

    [arr[right], arr[storeIndex]] = [arr[storeIndex], arr[right]];

    if (left < storeIndex - 1) stack.push([left, storeIndex - 1]);
    if (storeIndex + 1 < right) stack.push([storeIndex + 1, right]);
  }

  return arr;
}

这个版本用的内存不会比递归版本多太多，但栈的增长完全受我们控制。压栈前先判断区间长度大于 1，可以有效减少栈中无意义的区间。

6. 实际问题排查与避坑清单

6.1 手写快排最常见的 5 个错误

我在自己调试和帮别人单测的过程中，总结出手写快排最常见的几个错误，基本都集中在边界条件和随机数生成上。

第一个是随机索引越界。Math.floor(Math.random() * (right - left + 1)) + left 很容易写错，比如括号位置放错，导致取值落在 right + 1 上，数组直接访问越界，在 JavaScript 里返回 undefined，排序结果一团糟。

第二个是递归终止条件漏掉 left > right。当子数组为空时，left 可能比 right 大 1，如果不拦截，下一轮递归会操作一个无意义区间，最终栈溢出。

第三个是交换枢轴时把原数组搞乱。比如先把枢轴交换到最右，然后分区循环里又循环到了 right 位置，等于对枢轴自己做了无效操作，虽然结果碰巧没问题，但逻辑上是隐患。

第四个是忘记返回值或者错误地返回新数组。快排是原地排序，函数不需要返回新数组，但如果调用方误以为它返回了新数组，可能直接对原数组做了二次赋值，导致引用断裂。我建议统一约定：函数不返回数组，调用时传入的数组就是排序后的结果。

第五个是使用解构赋值交换元素时在极端性能场景下的性能损耗。解构赋值写法很清晰，但底层会产生临时数组，在百万级数据排序中会显著拖慢速度。如果你追求极致性能，建议手写临时变量交换：

javascript复制const temp = arr[i];
arr[i] = arr[storeIndex];
arr[storeIndex] = temp;

6.2 为什么真实项目里通常不会拿裸快排去替换 Array.prototype.sort

这是个很实际的问题。你费尽心思写的随机枢轴快排，在排序裸数组时可能还真不如 V8 自带的 Array.prototype.sort，因为现代引擎的排序实现是 TimSort 的变种，内部针对不同程度的有序数据做了一系列优化，还会根据数组元素类型和大小自动选择算法的复杂度。

那么手写快排的价值在哪？我的观点是三个：第一，它是算法思维训练的最佳样本之一，理解了快排的随机化思想，对分治、复杂度、概率这几个概念都会有更深的理解；第二，在浏览器或 Node 的某些场景下，如果你需要排序的不是数组，而是某个自定义的可迭代对象，原生方法不管用，你得自己写；第三，某些特殊约束下，比如只能使用 O(1) 额外空间，必须原地排序且不能用内置排序，这时手写快排是绕不开的方案。

我在项目里实际用的是自己封装的排序模块，底层是三路切分加小数组插入排序的混合体，性能比原生 sort 在重复值多的场景下要好一截。但要提醒一句，没有充分的 benchmark 支撑前，不要轻易替换原生方法。

6.3 调试快排的实用思路

调试排序算法最笨也最有效的办法，就是在分区函数前后打印数组状态，肉眼观察枢轴是否被放到了正确位置。我调试的时候习惯写一个小工具，先把原始数组拷贝一份，每次分区完走一个 assert 检查，人眼看太累了。

一个简单的校验函数长这样：

javascript复制function isSorted(arr) {
  for (let i = 1; i < arr.length; i++) {
    if (arr[i - 1] > arr[i]) return false;
  }
  return true;
}

然后在 quickSort 返回之后调用一次 isSorted，如果结果是 false，说明算法内部有逻辑错误。如果返回 true，但结果和预期顺序不一致，那大概率是交换逻辑里对“小于”和“小于等于”的判断写反了，结合打印中间数组就能很快定位。

还有一个小技巧，就是先拿一个极小的数组测试，比如 [3, 1, 2]，手动在纸上模拟一遍分区过程，再用代码跑一遍，对比每一步的数组变化。我每次写新的排序算法都会走这个流程，省掉大量排查时间。

写在最后：几点个人体会

这套随机枢轴快排折腾完之后，我最大的体会是：算法优化的瓶颈往往不是写不出代码，而是想不明白“为什么”。固定枢轴和随机枢轴的代码差异就那一行，但背后的概率思维、输入分布假设和工程权衡，才是真正值得花时间琢磨的东西。以后你再遇到排序性能问题，先别急着上什么黑科技，想想你的数据分布是什么样，最坏情况是什么，有没有可能被某个特定输入“精准命中”，再决定用哪种策略。

我自己的习惯是，只要排序模块要做成通用组件，枢轴一律随机化，成本极低、收益稳定。如果你对这块还想深入，三个方向可以自己研究：三数取中策略、内省排序（Introsort）、以及为什么 V8 的 sort 最终没有选择纯快排路线。这些内容展开又是一大篇，下次有时间再单独写。