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)。

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