企业官网建设流程全解析

如果只能让我给新人推荐一个必须吃透的排序算法，我会毫不犹豫地选快速排序。它不仅是面试题里的常客，更是分治思想、递归、随机化乃至工程折中的一次集中体现。不管是C语言、Java还是JavaScript，也无论是写一个纯前端表格的点击表头排序，还是在MapReduce里给海量数据做分组排序，你都会撞上快速排序的影子。这篇博文我会把快速排序从原理到实现、从优化到排错完整梳理一遍，顺手把常见的排序算法对比、非递归写法、字符串排序这些高频问题一并讲透。

1. 先搞清楚快速排序到底在“快”什么

1.1 分治思想是骨架

很多教材一上来就抛代码，我反而建议先把思想嚼透。快速排序的核心是分治：把一个数组拆成两部分，左边所有元素都不大于某个基准值，右边所有元素都不小于这个基准值，然后对左右两部分递归地做同样的事。每一次分区，至少有一个元素（基准）落到了最终位置，剩下的问题规模就缩小了。这个思路和归并排序的分治有本质区别——归并排序的分治发生在递归下降过程，合并发生在回溯过程，而快速排序的核心工作量就在“分区”这一步，递归返回时几乎什么都不用做。

有人拿整理书架来类比：你随手抽一本书当基准，把小于它的书放左边，大于它的放右边。这样基准书的位置就确定了，剩下的书虽然还是乱的，但规模变成了左右两摞，而且互相不会越界。接着对每一摞重复同样的操作，直到每摞只剩一两本。这就是快速排序最直观的画面。

分治带来了一个非常漂亮的性质：每一层递归处理的总数据量大约是O(n)，而递归深度平均是O(log n)，所以平均时间复杂度是O(n log n)。但这句话有个隐含前提——每次分区都要能把数组均匀切开。如果基准每次都挑到最大值或最小值，递归深度就退化成O(n)，总复杂度直接变成O(n^2)。这就是为什么基准选择是快速排序的命门，后面我会专门展开。

1.2 基准元素选择决定命运

基准选谁，直接决定快速排序的上限和下限。

• 固定选首元素或尾元素：实现最简单，但一旦遇到有序或逆序输入，每次分区都切出一块0和一块n-1，复杂度直接爆炸。
• 随机选基准：通过随机化消除了对输入分布的依赖，让任何输入的最坏情况都变成概率事件。这是工程中最常用的手段，代价仅仅是取一次随机数。
• 三数取中：取首、中、尾三个元素的中位数做基准。对于近似有序的数据效果非常好，能大幅减少最坏情况出现的概率，也是很多教科书和工程库的标准做法。
• 三数取中+随机化组合：兼顾了随机性和中位数的稳定性，在极端场景下更稳，但实现成本略高。

我在代码里最常用的是“随机选基准”，原因很简单：代码改动最小，效果立竿见影。三数取中在数据量小的时候优势不明显，数据量大了以后又要消耗额外的比较和交换，两者综合下来随机化是性价比最高的选择。不过也有例外——如果你明确知道数据是近似有序的，三数取中会表现得更好。

1.3 两种主流分区算法的对比

分区是快速排序的执行核心，这里有两个流派，初学者经常搞混。

Lomuto分区是教科书最爱：以最后一个元素为基准，用一个慢指针i和快指针j扫描数组，遇到比基准小的就和i交换，最后把基准换到i+1位置。代码短、好理解，但交换次数偏多。

Hoare分区是原始版本：两个指针分别从数组两端往中间走，左边找比基准大的，右边找比基准小的，找到就交换，直到两指针相遇。交换次数更少，常数因子更优，但边界条件容易写错，递归边界也不能简单地用基准位置来切。

从实际性能看，Hoare分区要比Lomuto快20%左右，尤其在数据量大的时候差异明显。从严谨性看，Lomuto更不容易出边界bug，适合学习阶段。我自己的实践是：学习用Lomuto，生产代码用Hoare，面试时看情况选。如果你背熟了Lomuto但面试官追问Hoare的细节，别慌，把两指针相遇的图示画出来讲清楚就行。

1.4 复杂度与稳定性，一次说透

快速排序的平均时间复杂度是O(n log n)，最坏O(n^2)，最好O(n log n)；空间复杂度主要是递归栈，平均O(log n)，最坏O(n)。它的“不稳定”体现在一个典型场景：键相同的元素在排序后相对位置可能改变。这点在排序对象只有数字时无感，但当你对一组带业务信息的对象做排序、且后续还要依赖稳定的相对顺序时，就得特别注意。

需要区分的是，稳定性是排序算法的固有属性，不是“能用快排解决”的问题。工程上如果要求稳定排序，一般会改用归并排序或插入排序的变体，或者给元素追加序号作为次关键字，把不稳定问题消解掉。我在做SQL排序需求时经常这么干：先按主排序键排序，如果存在相同键，再按一个自增序号排，这样用快排也能模拟出稳定效果。

2. 多语言实现：从教科书到工程代码

2.1 C语言实现与指针踩坑

先给一份教科书级别的C语言递归快排，使用的就是Lomuto分区，方便对比理解：

void swap(int* a, int* b) { int t = *a; *a = *b; *b = t; } int partition(int arr[], int low, int high) { int pivot = arr[high]; int i = low - 1; for (int j = low; j < high; j++) { if (arr[j] <= pivot) { i++; swap(&arr[i], &arr[j]); } } swap(&arr[i + 1], &arr[high]); return i + 1; } void quickSort(int arr[], int low, int high) { if (low < high) { int pi = partition(arr, low, high); quickSort(arr, low, pi - 1); quickSort(arr, pi + 1, high); } }

这段代码的坑集中在partition里。第一，循环条件是j < high而不是j <= high，因为high本身就是基准，不需要和自己比较；第二，i从low - 1开始，确保第一个比基准小的元素也能正确交换；第三，最终交换的是arr[i+1]和基准，而不是arr[i]。这三个细节任何一个错位，排序结果就会乱套。我见过很多新手在这三个地方来回翻车，调试半天才发现是边界差了一位。

工程上如果数据量极大，我建议把递归改成循环，或者把low和high用结构体打包传入，防止函数参数太多导致栈帧过大。C语言写快排最需要注意的是指针和边界，一旦越界，轻则排序错误，重则直接段错误。

2.2 Java实现与Arrays.sort的底层差异

Java里最常见的快排写法是用Arrays.sort，但很多人不知道它内部的行为。Java对基本类型数组用的是Dual-Pivot QuickSort（双轴快排），这是对经典快排的改造：一次选出两个基准，把数组分成三段，减少了比较次数和递归深度。而对对象数组用的是TimSort，一种基于归并的稳定排序。这个底层差异意味着：你对int[]排序和对Integer[]排序，走的不是同一套算法。

如果你需要自己实现快排，我建议把比较逻辑抽象出来，用Comparator传参，这样一套代码就能处理整数、字符串、对象字段排序。下面是一个支持泛型的简洁版本：

import java.util.*; public class QuickSort<T> { public void sort(List<T> list, Comparator<? super T> cmp) { sort(list, cmp, 0, list.size() - 1); } private void sort(List<T> list, Comparator<? super T> cmp, int low, int high) { if (low >= high) return; int pi = partition(list, cmp, low, high); sort(list, cmp, low, pi - 1); sort(list, cmp, pi + 1, high); } private int partition(List<T> list, Comparator<? super T> cmp, int low, int high) { T pivot = list.get(high); int i = low - 1; for (int j = low; j < high; j++) { if (cmp.compare(list.get(j), pivot) <= 0) { i++; Collections.swap(list, i, j); } } Collections.swap(list, i + 1, high); return i + 1; } }

在Java里做排序，优先用Arrays.sort和Collections.sort，这两个方法经过数年优化，性能远超手写版本。我见过的很多“手写快排比Arrays.sort快”的说法，基本都是在小数据量或特殊数据分布下的巧合，缺乏普适性。手写快排的意义在于理解原理、应对面试、以及在没有标准库的嵌入式环境里使用。

2.3 JavaScript的排序玩法与点击表头场景

JavaScript的Array.prototype.sort在不同引擎里实现差异很大。V8引擎早前用的是快排，后来改成了TimSort，原因是快排不稳定，容易给前端排序带来诡异的bug。现在你写[5,3,1,2,4].sort()，默认的排序规则是把元素转成字符串再比较，所以[10, 9, 100].sort()会得到[10, 100, 9]而不是[9, 10, 100]。这个坑几乎每个前端都会踩一次，解决办法永远是传比较函数。

前端最常见的快速排序应用场景是表格的点击表头排序。我的实现思路是这样的：

function sortTable(data, key, direction) { const dir = direction === 'asc' ? 1 : -1; return data.slice().sort((a, b) => { const av = a[key]; const bv = b[key]; if (av == null && bv == null) return 0; if (av == null) return -dir; if (bv == null) return dir; if (typeof av === 'number' && typeof bv === 'number') { return (av - bv) * dir; } return String(av).localeCompare(String(bv), 'zh-Hans-CN', { numeric: true }) * dir; }); }

这段代码处理了三个常见问题：空值排到最后、数字按数值排、中文字符串按拼音排。如果你直接拿字符串的>、<比较，中文排序会按Unicode码点排，跟用户预期的拼音顺序完全不同。localeCompare加numeric: true是我处理“字母数字组合的排序”的法宝，比如['item2', 'item10', 'item1']会正确排成item1, item2, item10，而不会排成item1, item10, item2。

JavaScript里手写快排并不难，难点在于理解内置sort的语义和引擎差异。我建议业务代码全用内置sort，只有面试或者做算法题时才手写。

2.4 非递归快排：显式栈消除递归隐患

递归快排虽好，但当数据规模达到几十万以上、且遇到逆序输入时，递归深度可能超过系统栈上限，导致栈溢出。解决办法是把递归改为显式的栈模拟。思路很直接：把(low, high)区间压栈，每次弹出处理，产生的新区间再压栈。下面给出一段C#风格的参考代码：

public void QuickSortIterative(int[] arr) { Stack<(int left, int right)> stack = new Stack<(int, int)>(); stack.Push((0, arr.Length - 1)); while (stack.Count > 0) { var (low, high) = stack.Pop(); if (low >= high) continue; int pi = Partition(arr, low, high); if (pi - 1 > low) stack.Push((low, pi - 1)); if (pi + 1 < high) stack.Push((pi + 1, high)); } }

这段代码里有个细节：先压左区间还是先压右区间，不影响正确性，但会影响栈的使用量。一般建议先压较大区间，让小区间优先处理，这样栈的深度能控制在O(log n)左右。这个技巧和递归版的尾递归优化异曲同工，我是实际排查栈溢出问题时才深切体会到的。

非递归版还有一个好处：方便在分区后做额外处理，比如对小区间直接切换插入排序，或者统计每个区间的数据规模，为动态负载均衡提供数据。如果你在做分布式排序，这种可控的区间任务分配方式远比递归好调试。

2.5 字符串与混合类型数据的排序技巧

对字符串做快速排序，最直接的方式是直接比较字符串大小。但字符串比较本身可能很耗时，因为要逐字符比较。一个工程技巧是：先按首字符分组，再对组内做二次排序，这样可以减少跨组比较。如果字符串很长、数量很多，还可以考虑先算出每个字符串的哈希值，按哈希排序后再对哈希冲突的组做精确比较。我在处理千万级别的日志字符串时采用过这个方案，性能提升非常明显。

字母数字组合的排序也有坑。比如身份证号、订单号这类字符串，按字典序排和按数值序排是完全不同的结果。前端处理表格排序时，我一般会先判断每列的数据类型：全数字就按数值排，混合字母数字就按自然排序规则排，纯中文就按拼音排。这个判断逻辑放在一个公共函数里，其他业务都能复用。

混合类型数据排在Java中使用Comparator就能优雅解决，JavaScript则要小心不同类型比较时隐式类型转换带来的诡异结果。我的原则是：排序前先统一类型，排序中显式指定比较规则，排序后做一次完整性校验。类型统一这一步看着简单，出错率却非常高，尤其当你拿到的数据来自多个表或多种接口时。

3. 性能优化的三板斧：真正让快排脱胎换骨

3.1 小数组切换插入排序

任何排序算法都有适用规模。快速排序在小区间上的递归调用和分区开销，超过了插入排序的直接比较损耗。所以工程实现里几乎都有一个阈值，数据量小于某个值（常见取10到20）时改用插入排序。这个优化在数据量大时效果尤其明显——递归树的底部有大量小区间，每个区间省掉一次分区调用，累计起来能减少大约10%到15%的排序时间。

我自己测试过，阈值取8到16之间差别不大，但取32以上反而可能变慢。具体原因和Java即时编译器的优化策略有关，不能一概而论。如果你想找最优阈值，可以针对目标数据规模做一个简单的基准测试，一般在10到20之间选一个整数就行。

这个优化思路不仅适用于递归版，非递归版同样可以加。每弹出一个区间，先判断区间大小，小于阈值就切换到插入排序。这样写虽然代码略复杂，但性能收益实打实。

3.2 三数取中和随机化的正确姿势

三数取中的实现不复杂：取首、中、尾三个位置的元素，找出中位数，把它和最后一个元素交换，然后继续执行标准分区。这样能避免有序数组下首元素做基准的悲剧，还能让基准更接近真正的中位数。三数取中在近似有序数据上效果很好，但在随机数据上提升有限，因为随机数据下任何基准的期望表现都差不多。

随机化的正确姿势是每次分区前，把基准元素与中间某个随机位置的元素交换。注意这里有个容易踩的坑：如果你用固定随机种子，那么在每次运行得到相同排序结果的同时，也失去了随机化的意义——因为最坏情况可能总是对应同一个输入模式。我一般用当前时间作为种子，而不是写死一个常量。

从理论上讲，随机化能让快速排序在任意输入上的最坏情况概率变得极低。但实际工程里，随机数生成本身也有开销。如果数据已经保证是随机的，或者来自实时流，有时不随机化反而更快。这个取舍没有标准答案，我的经验是：数据来源不可控就用随机化，数据来源可控就先用三数取中，性能不够再考虑随机化。

3.3 三路快排：解决重复元素的顽疾

标准快排在大量重复元素面前会严重性能退化。想象一个数组全是同一个值，固定选最后一个元素做基准，分区后左边是所有其他元素，右边是0个，递归深度直接O(n)，整体复杂度变成O(n^2)。解决思路是三分区：把数组分成小于基准、等于基准、大于基准三段。等于基准的元素原地不动，只递归处理小于段和大于段。

三路快排在处理重复数据时的性能提升是数量级的。数据全是相同值时，一趟分区后左右区间都为空，排序立即结束，复杂度降到O(n)。这个算法在Java的Arrays.sort对基本类型的实现中也用到了类似思路。我处理过几千万条只有几十个不同取值的业务数据时，用三路快排的方案比普通快排快了近十倍。

3.4 从快排到双轴快排

双轴快排是Java 7之后Arrays.sort对基本类型数组的默认实现。它一次选出两个基准，把数组分成三段，理论上可以把比较次数减少三分之一左右。双轴快排并非在所有场景下都优于单轴快排，但它对数据分布的适应性更强。我自己没有生产环境手写双轴快排的需求，因为标准库已经优化得足够好。但如果你在做算法竞赛或底层库，理解双轴快排的分区细节非常有价值。

双轴快排的实现难点在于两个基准的选取和分区结束后的递归区间划分，代码长度几乎是单轴的两倍。如果你不是必须自己实现，建议直接用标准库。真正重要的不是记住双轴快排的每一行代码，而是理解它为什么比单轴快——减少递归深度、每次分区更多元素落位、缓存命中率更好。

4. 实际场景选型与应用经验

4.1 数据库排序与快排思想的渗透

MySQL的ORDER BY底层实现会根据数据量和索引情况选择排序策略。如果是内存排序，MySQL会用优先队列或快速排序的思路；如果数据量超过缓冲区，会退化成归并排序写临时文件。SQL Server的分组排序、组内排序本质上也是在排序后做窗口函数计算，比如ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)就是先在分区内排序，再赋予行号。

这里我想强调一个工程认知：从外部看，快排是一种算法；从内部看，很多数据库的排序实现都融合了快排和归并的思想。比如MySQL的filesort算法里，有一个阶段叫做“快速排序优化”，在内存排序部分用的就是类快排算法。理解这一点，你就能明白为什么数据库排序在小数据集上非常快，而一旦结果集超过缓冲区，性能会断崖式下跌——因为算法切换了。

我在实际SQL调优时，看到一个慢查询是因为全表排序，第一步不是优化排序算法，而是尝试减少排序的数据量。加索引把排序下推到索引扫描阶段，或者改分批查询，往往会比任何排序算法层面的优化都见效。

4.2 前端点击表头排序背后的取舍

点击表头排序是快速排序思想在业务代码里最常见的落地场景。前端排序的难点不在算法本身，而在交互体验。比如用户点击表头，期望的是瞬间完成排序，而不是看到卡顿。数据量在几千条以内时，不管用什么排序算法都感觉不到差别；但数据量上万甚至几万条时，排序性能和渲染性能就开始撕裂了。

我处理表格排序一般分三步：第一步判断数据规模，几千条直接前端排序加虚拟滚动；几万条以上考虑后端排序，每次只传当前页数据；第三种折中方案是前端做一次缓存排序，把排序后的数据保存起来，后续翻页直接取缓存。这三种方案的选型依据是数据量和交互频率，而不是算法优劣。

前端排序还有一个容易被忽略的细节：排序稳定性。如果你先按时间排序，再按部门排序，稳定排序会让同一部门内的数据保持按时间排序的相对顺序。JS的Array.prototype.sort在V8里现在是稳定排序，但早期不是。所以写代码时不要依赖引擎行为，需要对稳定性有明确需求时，就手动追加次关键字。

4.3 大数据排序：MapReduce中的快速排序思想

在大数据场景下，单机排序不够用了，但快排的思想依然被广泛使用。MapReduce的排序流程是：Map端把数据写成带键值对的记录，经分区器分到不同Reduce任务，每个Reduce任务收到数据后先做内存排序，再用归并输出。这个内存排序的底层，不同实现会选择快排或堆排序。头歌上那些“MapReduce排序—分组排序”“倒排序索引”的关卡，本质上就是在练这些流程的细节。

我自己在调MapReduce作业时，最常见的性能问题不是排序本身，而是分区不均导致某些Reduce任务数据量极大。快排在这里的核心启示是：一次排序把数据分成多个互不干扰的区间，分布式系统里的分区思想其实和快排的分区一脉相承。所以学好快排，不仅仅是学会一个算法，而是学会“分而治之”这种解决大规模问题的通用策略。

在流处理或其他大数据框架里，类似Kafka的分区策略、数据库的分库分表逻辑，背后都有分区思想的影子。快速排序在这里更像是思维训练，帮助你建立拆分问题的直觉。

4.4 从八大排序算法对比看选型思路

网上流行的“八大排序算法总结”通常包括：冒泡、选择、插入、希尔、归并、快速、堆排序、基数排序。选型时不能只看时间复杂度，还要考虑稳定性、空间复杂度、常数因子、数据特征。

这个表里没有绝对最优解。数据量小用插入排序最快，数据量大且随机用快排，要求稳定用归并，内存紧张用堆排序，数据范围小用基数排序。CLRS里对选择排序循环不变量的证明可以用来体会算法正确性的形式化论证，但对选型并没有直接帮助——工程选型永远先看数据特征和业务约束，再看理论复杂度。

我在面试中常问候选人的一个问题就是：如果要对一个几乎有序的数组排序，你会用什么？答案是插入排序，因为它的最好情况复杂度是O(n)。很多候选人第一反应是快排，正因为没意识到数据特征决定了算法选择。

4.5 特殊排序问题：拓扑排序和三值排序

有人会把拓扑排序混进排序算法里，其实拓扑排序解决的是有向无环图中的先后依赖问题，跟比较排序完全不同。它在工程里的典型场景是构建系统里的依赖解析：哪些模块必须先编译，哪些可以并行编译。虽然都叫排序，但图算法和比较排序的思维方式差异极大。

三值排序是USACO里的一道经典题，给定只有三个值的数组，要在O(n)时间内排序。思路是一次扫描，用三个指针把0、1、2分别归位。这个题的工程价值在于：当数据的取值域极小且已知时，计数排序或三指针扫描远比快速排序高效。这提醒我们一个常被忽略的原则：快速排序是通用算法，但永远有更适配特定场景的特化算法存在。

我自己做SQL调优时也遇到过类似的场景：某个字段只有两个取值，但查询计划里出现了排序操作。我强制改用了分组聚合和条件统计，绕过了排序，查询时间从秒级降到了毫秒级。排序本身不可怕，可怕的是默认要用通用方案解决所有问题。

5. 常见问题排查与实操避坑

5.1 递归深度与栈溢出

快速排序最常见的线上事故就是Stack Overflow。特征非常明显：数据量大、输入有序或近似有序、选用固定基准。排查思路第一是看数据分布，第二是看代码写法。递归深度是O(n)时，百万级数据就足以把系统栈压爆。

我的规避方案是三层防线：第一层，基准选择用三数取中或随机化，避免有序输入直接命中最坏情况；第二层，开启非递归实现，把递归栈搬到堆上，彻底规避系统栈限制；第三层，在递归函数开头加一个区间规模判断，小区间直接切插入排序，减少递归深度。三层叠加后，即使数据分布再恶劣，栈溢出的概率也非常低。

5.2 大量重复元素导致性能退化

重复元素的性能退化不像栈溢出那么好识别，因为排序结果看起来是正确的，但耗时从几十毫秒涨到几十秒。复现方法是构造一个全是相同值的数组做基准测试。标准快排和随机化基准快排都会性能退化，三路快排则是这个场景的官方解药。

除此之外还有一个经验：如果重复元素比例很高，可以考虑先做一次数据压缩，把每个唯一值连同出现次数记录下来，对唯一值排序后再展开。这个方法在业务报表排序中特别实用，比如统计每个城市的订单量，城市名只有几百个，但数据行有几千万。先聚合后排序，复杂度直接从O(n log n)降到O(k log k)加O(n)，k远小于n时效果惊人。

5.3 逆序数据的极端情况

逆序数组对固定选首元素的快排来说是最标准的最坏情况，但对三数取中就能轻松化解。排查逆序输入的有效办法是：专门构造一个逆序数组跑一次排序，观察递归深度和耗时。如果耗时异常，第一检查基准选择，第二检查递归条件。

这里还要注意一个被忽视的点：分区后的边界处理。标准写法是递归调用时左区间取(low, pi-1)，右区间取(pi+1, high)。如果你把基准位置也包含进递归区间，会在极端情况下造成死循环或无限递归。我排查过一个线上死循环事故，最后发现就是边界写错导致区间无法缩小。

5.4 快排正确性与性能验证三板斧

写完快排后怎么确认它正确且够快？我推荐三套验证方案。

第一，正确性验证：准备几组特殊数据——空数组、单元素数组、有序数组、逆序数组、全部相同元素数组、随机大数组。每组都跑一遍，然后和后端接口返回的排序结果对比。特殊数据覆盖了快排最容易出错的边界，随机大数组则验证常规路径。

第二，性能基准测试：对比手写快排和标准库排序在同一组数据上的耗时。数据量从一万到一百万递进，观察曲线是否接近O(n log n)。如果百万级数据耗时不是十毫秒到几十毫秒级别，就需要检查分区函数的常数因子。如果曲线明显上翘，说明遇到了最坏情况，检查基准选择。

第三，内存监控：用工具观察排序过程中的内存变化。快排的空间复杂度是O(log n)，内存应该平稳。如果内存突然飙升，可能是递归过深，也可能是数据拷贝过多。内存变化曲线是排查性能问题的重要线索，比单纯看时间更可靠。

5.5 排序问题的调试技巧

调试排序算法，我最常用的工具就是打印。在partition的入口打印当前区间和基准值，在出口打印分区后的数组。打印几轮之后，能直观看到分区是否符合预期。特别是Hoare分区，两个指针的相遇条件非常容易错，打印一次交换过程立刻就能定位问题。

另一种高效调试方式是写一个排序正确性断言工具：排序完成后遍历数组一遍，检查后一个元素是否始终不小于前一个。这个断言在单元测试里加上，会帮你拦截掉大量回归问题。我用这个断言工具顺手排查过SQL Server分组后组内排序序号错乱的问题——本质是排序键不唯一导致顺序不稳定。

调试的经验之谈是：不要只盯着排序结果看，要看中间状态。排序是过程性的算法，结果对了不代表过程对了。过程错了但在某些输入上恰好结果对，才是最隐蔽的坑。

6. 最后分享一点个人体会

我在实际项目里被快速排序“坑”过两次，一次是百万级有序数据导致递归栈溢出，一次是海量重复值导致耗时暴增。这两次事故让我彻底明白：算法不是背下来就完事的，必须理解它的适用边界和失效模式。快速排序的威力建立在基准选择的合理性和数据分布的多样性之上，一旦这两个前提被打破，它就会从最快的排序变成最慢的排序之一。

如果你现在正在学排序算法，我建议动手把每个算法都实现一遍，然后跑一组相同的数据做对比，记录下每次的耗时和递归深度。这个记录过程比你看任何博客都有效，因为你会亲眼看到理论上的复杂度和实际运行之间的鸿沟与关联。排序算法是少数几个“代码就几十行、但足够你琢磨一辈子的细节”的主题，快速排序更是其中最有代表性的一个。