山月刀岚月刀如果你准备过Java后端面试，大概率遇到过这么一个问题："讲讲常见的排序算法，各自的时间复杂度和稳定性怎么样？"如果你没准备过面试，工作中也大概率听过同事讨论"排序算法时间复杂度""堆排序怎么实现"这类话题。发现一个很有意思的现象：很多人能背出冒泡排序、选择排序、堆排序的概念，但真让他们白板手写一遍，或者从底层讲清楚为什么堆排序建堆是O(n)而不是O(n log n)，就会卡壳。排序算法本身不难，难的是把整个体系串起来，既能手写代码，又能说清楚每个循环变量在干什么、为什么这样选型、稳定性到底是怎么被破坏的。
这篇文章不打算铺开讲所有排序算法，而是把冒泡排序、选择排序、堆排序这一条线彻底讲透。我尽量把代码、推导、面试高频追问和个人踩坑经验揉在一起，适合正在刷面试题的Java学习者，也适合复习数据结构与算法的工程师。
1. 三种排序的全局认知：复杂度、稳定性与适用边界
很多人学排序算法是孤立地学，学完冒泡忘选择，学完堆排序不知道它和选择排序有什么关系。这其实很可惜。如果你把冒泡、选择、堆排序放在一起看，会发现它们之间存在一条清晰的逻辑递进：从最基本的"相邻交换"，到"选最小值交换"，再到"用堆结构快速选出最小值"。复杂度层级从O(n^2)一路走到O(n log n)，这背后是算法思想上的一次次升华。
先看一张整体对照表：
| 算法 | 平均时间复杂度 | 最好时间复杂度 | 最坏时间复杂度 | 空间复杂度 | 稳定性 |
|---|---|---|---|---|---|
| 冒泡排序 | O(n^2) | O(n) | O(n^2) | O(1) | 稳定 |
| 选择排序 | O(n^2) | O(n^2) | O(n^2) | O(1) | 不稳定 |
| 堆排序 | O(n log n) | O(n log n) | O(n log n) | O(1) | 不稳定 |
注意几个关键点。
冒泡排序的"最好O(n)"是有条件的。只有在数组已经有序、且你实现了"提前终止"优化的前提下，才能达到O(n)的最好复杂度。如果你写的是最基本的双层循环不判断是否发生交换，那么无论数据长什么样，它都是比较固定次数，复杂度稳如磐石地维持O(n^2)。
选择排序的最好/最坏/平均时间复杂度全部是O(n^2)。这点经常被忽略。有人以为"选择排序每轮只交换一次，肯定比冒泡快"，但时间复杂度层面它依然属于O(n^2)家族。它只是把比较和交换解耦了，比较次数依然是差不多n(n-1)/2次。
堆排序是"基于比较的排序"里理论上的天花板级别选手。计算机科学里有一个结论：基于比较的排序算法，时间复杂度的下界是O(n log n)。堆排序恰好达到了这个下界。但注意，它和快速排序、归并排序虽然复杂度同级，实际运行速度却通常更慢，原因后面第四章细说。
稳定性维度也很有意思。冒泡是稳定排序，选择排序和堆排序都是不稳定排序。这里的稳定性指：如果两个元素值相等，排序后它们的相对顺序保持不变。为什么冒泡能稳定？因为相邻元素相等时不会交换，值相等的元素相对位置自然不变。为什么选择排序不稳定？后面会用一个具体例子说明。
这三种算法的适用边界：
- 冒泡排序：教学演示价值远大于实际使用价值。数据量很小（比如几十个以内）、且你不在乎性能时可以用。
- 选择排序：交换次数最少是它的核心竞争力。当"交换"操作的成本极高（比如交换的是大对象引用且数据还在磁盘/网络上）时，选择排序的"每轮最多一次交换"就是实打实的优势。
- 堆排序：适合需要"在动态数据中不断取最大/最小值"的场景，比如优先级队列、Top K问题。但它本身作为排序工具，在实际工程中用得反而不多，因为JDK和大多数框架的排序都走了快排或归并路线。
认知框架搭好之后，我们来逐一把每个算法揉碎了讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 冒泡排序：从教学案例到工程弃用的完整分析
2.1 冒泡排序的核心思想与基础实现
冒泡排序的朴素思想是：在一趟遍历中，把相邻的两个元素两两比较，如果前一个比后一个大，就交换它们。这样一趟走下来，最大的元素就像气泡一样"冒"到了数组末尾。重复这个过程，每一趟把当前未排序部分的最大值归位，n-1趟之后数组完全有序。
基础实现几乎是Java入门的必修课：
java复制public class BubbleSort {
public static void bubbleSort(int[] arr) {
if (arr == null || arr.length < 2) {
return;
}
int n = arr.length;
// 外层循环控制排序轮数，总共需要 n-1 轮
for (int i = 0; i < n - 1; i++) {
// 内层循环控制每一轮的比较范围
// 已经归位的元素不需要再参与比较，所以是 n - 1 - i
for (int j = 0; j < n - 1 - i; j++) {
if (arr[j] > arr[j + 1]) {
// 交换相邻元素
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
}
}
}
}
}
这个代码里有几个容易写错的地方，我结合自己带新人的经验说一下。
**内层循环上限到底是 n-1 还是 n-1-i？**两个都有可能出现，取决于外层循环变量从0还是从1开始。上面的写法外层从0开始，第i轮结束后有i+1个元素已经沉底，所以内层比较区间的右边界是n-1-i。如果你改成外层从1开始，那内层就变成 n-i。我个人建议记忆"外层第i轮结束后，数组末尾i+1个元素已就位"，这样永远不会写错边界。
**为什么外层只要 n-1 轮而不是 n 轮？**因为最后一轮只剩下一个元素没有归位，它天然就是最小的，不需要再比较。写 n 轮也不会越界，但会多做一轮无意义的遍历。
2.2 冒泡排序的两个关键优化：提前终止与记录最后交换位置
基础版本每次都会老老实实跑完 n-1 轮，哪怕数组已经有序。但在实际数据中，很多数组是"部分有序"的，这时候基础版本就做了大量无用功。
**优化一：提前终止。**在每一轮开始之前记录一个标志位，如果整轮遍历下来没有任何一次交换，说明当前数组已经有序，直接退出外层循环。
java复制public static void bubbleSortOptimized(int[] arr) {
if (arr == null || arr.length < 2) {
return;
}
int n = arr.length;
for (int i = 0; i < n - 1; i++) {
boolean swapped = false;
for (int j = 0; j < n - 1 - i; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
swapped = true;
}
}
if (!swapped) {
break;
}
}
}
加了这两行之后，如果输入一个已经完全有序的数组，第一轮扫描发现没有任何交换，直接退出，整体复杂度降为O(n)。
**优化二：记录最后一次交换位置。**这个优化知道的人不多，但效果很不错。思路是：某一轮比较中，最后一次发生交换的位置之后的元素，已经全部有序。下一轮比较只需要扫描到"最后交换位置"即可，不需要扫描到 n-1-i。
java复制public static void bubbleSortWithLastSwap(int[] arr) {
if (arr == null || arr.length < 2) {
return;
}
int n = arr.length;
int lastSwapIndex = n - 1; // 当前轮次需要扫描到的右边界
while (lastSwapIndex > 0) {
int curLastSwap = 0; // 记录本轮最后一次交换的位置
for (int j = 0; j < lastSwapIndex; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
curLastSwap = j;
}
}
lastSwapIndex = curLastSwap;
}
}
这个优化对"数组前半部分乱序，后半部分已经有序"的场景特别有效。我实测过一个100万条数据的数组，其中前50万乱序、后50万有序，优化二比基础版本快近一倍。
2.3 为什么冒泡排序在生产中几乎被淘汰
抛开"比较次数多"这个表面原因，冒泡排序真正的问题在于元素移动效率低。每交换一次元素，数据就要发生一次内存读写。如果数组特别大，而元素又恰好是倒序，冒泡排序几乎要交换 n(n-1)/2 次，这个量级的缓存命中率非常差。
对比之下，插入排序虽然平均复杂度也是O(n^2)，但它对"局部有序"数据极其友好，常数很小。快速排序和归并排序更是把复杂度拉到了O(n log n)级别。所以在真实项目中，你几乎不会看到有人用冒泡排序。我上家公司在代码评审里直接把冒泡排序列为"不允许出现的代码"，不是因为它是错的，而是因为它是最差解。
不过，冒泡排序在教学上依然有不可替代的价值。它是理解"交换排序"思想的最小模型，也是很多人在白板面试时能最快写出来的排序算法。如果面试官让你写一个排序，你不确定自己能漂亮地写完快排，冒泡是一个保底选择——至少能把功能跑对。
3. 选择排序：交换次数最少的O(n^2)排序，但不稳定
3.1 选择排序的核心逻辑与实现
选择排序的思想比冒泡更直接：每一轮从"未排序区域"中找到最小值，把它和未排序区域的第一个元素交换。这样每轮结束后，最小值就"选择"到了正确的位置上。n-1轮之后，所有元素有序。
java复制public class SelectionSort {
public static void selectionSort(int[] arr) {
if (arr == null || arr.length < 2) {
return;
}
int n = arr.length;
for (int i = 0; i < n - 1; i++) {
// 找到 [i, n-1] 区间内最小值的下标
int minIndex = i;
for (int j = i + 1; j < n; j++) {
if (arr[j] < arr[minIndex]) {
minIndex = j;
}
}
// 将最小值交换到 i 位置
if (minIndex != i) {
int temp = arr[i];
arr[i] = arr[minIndex];
arr[minIndex] = temp;
}
}
}
}
代码非常简洁。外层循环控制"选出第i小的元素"，内层循环扫描剩余区域找最小值下标。这里有个细节：先找到最小值的下标，再交换。很多人写成"一边找一边交换"，那其实是另一种退化了的排序，不会比选择排序快，反而增加了交换次数。
我统计过一组数据：对于1万个随机整数，选择排序大概需要比较约5000万次，但只需要交换约1万次。冒泡排序同样比较5000万次，交换次数却可能高达2500万次。当元素交换成本远高于比较成本时，选择排序的优势就体现出来了。
3.2 选择排序为什么不稳定：一个经典的反例
这是面试里几乎必问的点。很多人背结论"选择排序不稳定"，但说不出原因。直接看例子：
假设数组是 [5a, 8, 5b, 2, 9]，其中5a和5b都等于5，只是我用下标区分它们以观察相对顺序。
第一轮：扫描 [5a, 8, 5b, 2, 9]，找到最小值2，下标为3。把2与5a交换，数组变为 [2, 8, 5b, 5a, 9]。
此时两个5的相对顺序已经变了：排序前5a在5b前面，排序后5a反而跑到了5b后面。这就是不稳定性的来源——选择排序会把最小值从很远的地方直接交换到前面，跨越了若干个元素，导致等值元素的原有相对顺序被破坏。
用一句人话总结：冒泡排序只交换相邻元素，所以等值元素永远不会"擦肩而过"；选择排序的交换是"远距离传送"，一等值元素可能被甩到另一个等值元素的后面。
3.3 选择排序与冒泡排序的效率对比实测
我直接用JMH跑过一个简单的基准测试，随机生成的10万条整型数据，结果如下（单位毫秒，仅供参考）：
| 算法 | 随机数据耗时 | 近乎有序数据耗时 | 完全倒序数据耗时 |
|---|---|---|---|
| 冒泡排序（优化二） | 约6800 | 约5 | 约8500 |
| 选择排序 | 约4200 | 约4200 | 约4200 |
| 冒泡排序（基础版） | 约9800 | 约9800 | 约9800 |
几组数据对比下来，结论非常清晰：
- 冒泡排序的"提前终止"优化对有序数据极有效，但它本质是碰运气——如果数据恰好有序就快，如果无序就慢。
- 选择排序的时间消耗非常稳定，不随数据状态剧烈波动，因为它无论如何都要比较完全部剩余元素。
- 选择排序在平均情况下比冒泡基础版快一半左右，因为省掉了大量交换。
有些面试题会问"如何让选择排序稳定"。思路是：不交换，而是把最小值到当前位置之间的元素整体往后平移一个位置。这样相当于数据插入到正确位置，其他元素的相对顺序不变。代价是时间复杂度没变，但交换变成了移动，代码复杂度上去了。实际工程中很少有人这么干，因为如果已经到了需要优化选择排序稳定性的场景，不如直接用归并排序。
4. 堆排序完整拆解：建堆、调整、排序的递推过程
4.1 从二叉堆到数组映射：堆排序的底层数据结构
堆排序是这三种算法里唯一需要引入"数据结构"概念的。它和优先队列（PriorityQueue）共用一个底层模型——二叉堆。
二叉堆是一棵完全二叉树，可以用数组连续存储，不需要指针。关键点在于父子节点的下标关系：假设数组下标从0开始，那么对下标为i的节点，其左孩子下标为2i+1，右孩子下标为2i+2，父节点下标为(i-1)/2。
堆又分为大顶堆和小顶堆：
- 大顶堆：每个节点的值 大于等于 左右孩子节点的值。堆顶是最大值。
- 小顶堆：每个节点的值 小于等于 左右孩子节点的值。堆顶是最小值。
堆排序用大顶堆。每一轮把堆顶（最大值）和当前堆的最后一个元素交换，然后堆大小减一，再对新的堆顶做"下沉"调整。这样一轮轮下来，最大值依次归位到数组末尾，最终整体有序。
这里有一个最常见的思想误区：堆排序不是"不断从堆里弹出最大值输出"吗？如果输出到另一个数组，空间复杂度就变成O(n)了。经典的堆排序之所以空间复杂度是O(1)，是因为它利用原数组做交换——最大值交换到末尾后，这个位置就永久退出了堆的逻辑范围，下次堆排序不再关心它。循环往复，数组从后往前逐步有序。
4.2 建堆过程：从最后一个非叶子节点开始下沉
堆排序的第一步是"建堆"：把一个无序数组调整成一个大顶堆。
最直观的思路是从上往下调整，也就是"上浮"。但标准做法恰恰相反：从最后一个非叶子节点开始，从下往上依次做下沉调整。
最后一个非叶子节点的下标是 n/2 - 1（n为数组长度，下标从0开始）。为什么？因为最后一个节点下标是n-1，它的父节点就是(n-1-1)/2 = n/2 - 1。这个节点是最后一个有孩子的节点，从它开始往前扫描，就能保证每个子树都被调整成堆。
下沉调整的核心逻辑是：比较当前节点和它的左右孩子，找出三者中最大的那个；如果最大的不是当前节点，就交换它，然后继续对被交换下去的孩子节点做同样的下沉操作，直到当前节点到达合适位置。
java复制// 下沉调整：将以 index 为根节点的子树调整成大顶堆
private static void siftDown(int[] arr, int index, int heapSize) {
int left = index * 2 + 1;
int right = index * 2 + 2;
int largest = index;
if (left < heapSize && arr[left] > arr[largest]) {
largest = left;
}
if (right < heapSize && arr[right] > arr[largest]) {
largest = right;
}
if (largest != index) {
swap(arr, index, largest);
// 交换后，largest 位置的子树可能被破坏，继续下沉
siftDown(arr, largest, heapSize);
}
}
注意这里的 heapSize 参数，它表示当前堆的逻辑大小。很多人在堆排序时把数组长度写死在代码里，导致"已经归位到末尾的最大值"又被重新参与下沉，排序结果出错。这是堆排序手写时最典型的bug。
4.3 建堆的时间复杂度：为什么是O(n)而不是O(n log n)
这是面试的进阶问题，也是很多人最费解的地方。直觉上，对n个节点每个都做一次下沉，每次下沉最坏O(log n)，加起来不就是O(n log n)吗？
这个直觉在"每个节点都从根下沉到叶子"的假设下是对的，但事实不是这样的。数组里大部分节点位于堆的底层，它们下沉的路径很短。准确计算方式是把每一层节点的数量乘以该层节点可能下沉的最大深度，再求和。
假设堆的高度是h（从0开始计数），那么：
- 第k层的节点数量为 2^k 个
- 第k层的节点最多需要下沉 h - k 层
所以总工作量是：
S = Σ [2^k * (h - k)]，k 从0到h-1
这个级数求和的结果是 S = 2^(h+1) - h - 2，也就是O(n)级别。直觉上的解释是：越靠近底层的节点数量越多，但它们需要的调整距离越短；越靠近顶层的节点数量越少，需要的调整距离虽然长，但总量不大。综合下来，整体是线性的。
我用一个简单例子验证：数组 [1, 2, 3, 4, 5, 6, 7] 建堆。共7个节点，最后一个非叶子节点下标是7/2 - 1 = 2，即值为3的节点。从它开始下沉：
- 节点3和6、7比较，与7交换。
- 节点2（值为2）和4、5比较，和5交换。
- 节点1（值为1）和现在的左右孩子5、7比较，和7交换，然后下沉继续和6、3比较，与6交换。
这一共做了多次比较，但不超过常数倍的7。如果写成O(n log n)，那7个节点最多需要约7*3=21次操作，实际下沉操作量远低于这个值。
4.4 堆排序完整代码与执行过程
建堆完成之后，堆排序的"排序"阶段就非常简单了：把堆顶（最大值）和当前堆的最后一个元素交换，heapSize减一，然后从堆顶做一次下沉调整。重复 n-1 次。
java复制public class HeapSort {
public static void heapSort(int[] arr) {
if (arr == null || arr.length < 2) {
return;
}
int n = arr.length;
// 1. 建堆：从最后一个非叶子节点开始，自下而上做下沉
for (int i = n / 2 - 1; i >= 0; i--) {
siftDown(arr, i, n);
}
// 2. 排序：堆顶与末尾交换，缩小堆范围，重新调整
for (int i = n - 1; i > 0; i--) {
swap(arr, 0, i); // 堆顶最大值放到末尾
siftDown(arr, 0, i); // 注意 heapSize 变成了 i
}
}
private static void siftDown(int[] arr, int index, int heapSize) {
while (true) {
int left = index * 2 + 1;
int right = index * 2 + 2;
int largest = index;
if (left < heapSize && arr[left] > arr[largest]) {
largest = left;
}
if (right < heapSize && arr[right] > arr[largest]) {
largest = right;
}
if (largest == index) {
break;
}
swap(arr, index, largest);
index = largest;
}
}
private static void swap(int[] arr, int i, int j) {
int temp = arr[i];
arr[i] = arr[j];
arr[j] = temp;
}
}
我之前写的是递归版本的siftDown，这里是迭代版本。实际工程中我更喜欢迭代版本，因为它不存在递归栈溢出的风险，而且对堆这种"调整深度有限"的场景，迭代版本性能也略好。
排序阶段的执行细节：第一次交换后，最大值已经在数组末尾。此时堆的范围是[0, i-1]，堆顶元素可能不满足堆性质，所以需要对下标0执行下沉调整。等等，有人会问：交换的是堆顶和最后一个元素，最后一个元素到了堆顶，那原来堆顶下面其他的子树呢？答案是它们没变，仍然各自保持着大顶堆性质——因为建堆完成后，除了堆顶之外，每个子树的堆性质都是成立的。现在只是把堆顶的值换成了一个较小的值，它向下走的过程中，如果遇到比自己大的孩子就交换，一路下沉到合适位置，整棵树重新满足大顶堆性质。
这个"其他子树保持堆性质"的特性很关键，它是堆排序每一轮只需要O(log n)调整的核心原因。不需要重新建堆，只需要一次下沉。
4.5 堆排序的优缺点：为什么理论最优但工程中不是默认选择
堆排序在理论上达到了O(n log n)的复杂度下界，空间复杂度O(1)，看起来非常完美。但实际工程中并没有成为默认排序，快速排序和归并排序反而更常见。原因有三个：
**第一，堆排序不稳定。**等值元素的相对顺序会被打乱。很多业务场景要求稳定排序，比如数据库order by多字段时，或者对对象列表按某个字段排序时，稳定性能保证相同字段的对象保持原有顺序。
**第二，堆排序的缓存局部性差。**堆排序的访问模式是"跳跃式"的——堆顶和堆底交换，下沉过程中也是在数组的不同位置间跳跃。CPU缓存对连续内存访问非常友好，对随机跳跃访问很头疼。快排在分区阶段访问的是连续区间，缓存命中率远高于堆排序。
**第三，堆排序的常数比较大。**虽然复杂度同为O(n log n)，但堆排序每一轮都需要多次比较和交换，且比较次数比快排多不少。我实测过10万随机数据，快排比堆排序快大约2到3倍，归并排序也通常比堆排序快。堆排序的优势更多体现在"理论最优和无需额外内存"这两个维度上。
但是，堆排序的思想在另一个领域极其重要：优先级队列和Top K问题。JDK的PriorityQueue底层就是小顶堆，往里面加入一个元素是O(log n)，取出最小值是O(log n)。如果需要从100亿个数里找最大的100个，用堆维护一个大小为100的小顶堆，遍历一遍数据即可，空间复杂度O(1)。这种场景下，堆结构的作用是任何其他算法都替代不了的。
5. 面试高频追问与实战选型建议
5.1 面试官最爱追问的几个点
面试官拿到"排序算法"这个话题时，一般不会只让你默写代码。高频追问基本集中在下面几个方向：
追问一：这三种排序的稳定性分别如何？为什么？
回答框架：冒泡稳定，因为只交换相邻元素，等值元素不交换；选择不稳定，因为最小值可能跨越多个位置交换过来，破坏等值元素的相对顺序；堆不稳定，因为堆顶与堆底交换时，堆底元素可能跑到堆顶前面，大跨度交换本身就是不稳定性的来源。
追问二：堆排序建堆为什么是O(n)？
回答框架：从最后一个非叶子节点向上依次下沉，底层节点数量多但下沉路径短，顶层节点数量少但下沉路径长，求和后总操作量是线性的。千万不要回答"每个节点下沉一次所以是O(n)"，这个说法逻辑上不严谨，面试官会追问细节。
追问三：手写堆排序时最容易错的地方在哪里？
结合我自己的体验，最经典的错误是两个：一个是建堆起点算错，把 n/2 当成了起点，而不是 n/2 - 1（下标从0开始时）；另一个是排序交换后下沉时传的堆大小不对，有人写成整个数组长度，结果已经归位的最大值又被调整到堆顶，排序结果一团糟。记住一句话：交换完之后，堆的逻辑大小必须减一。
追问四：Arrays.sort在Java里底层用的什么排序？
这个问题经常出现在Java基础面试里。JDK 8之后，Arrays.sort针对基本类型数组使用Dual-Pivot快速排序，针对对象数组使用TimSort（归并排序的优化版本）。前者不稳定但快，后者稳定。这个知识点把排序算法和Java源码连接起来了，能答上来会加分很多。
追问五：现实业务中，你会在什么场景用哪种排序？
这个问题没有唯一答案。我一般这样答：
- 数据量小（几十到几百）且对稳定性有要求：插入排序或归并排序。
- 数据量中等、不要求稳定：快速排序。
- 需要稳定排序且数据量较大：归并排序。
- 需要内存占用严格O(1)：堆排序。
- 需要从海量数据中取Top K：用堆维护一个小顶堆。
5.2 实战中排序算法选型的三条经验
第一，不要手写排序，优先使用JDK和框架内置的排序方法。这是个很反直觉的点，因为排序算法是学习数据结构的必修课，但真实业务代码里不需要自己写。Java内置的Arrays.sort和Collection.sort都经过极其充分的优化，针对不同数据规模切换策略。你手写的堆排序很难跟它们比性能。学习排序算法是为了理解原理和过面试，不是为了在生产代码里替代标准库。
第二，数据量小的时候，简单排序反而可能更快。JDK源码里，DualPivotQuickSort在数组长度小于47时直接切换到插入排序，就是这个原因。因为小数据量下，递归带来的栈操作和函数调用开销比简单的双重循环更大。如果你处理的数据只有几十条，不用纠结，直接调Arrays.sort就行。
第三，"数据是否近乎有序"是选型的重要考量。如果数据量不大且接近有序，插入排序是最佳选择（几乎O(n)）。如果数据规模大且分布未知，直接用快速排序。如果排序结果要展示给用户且数据规模大，考虑稳定性时用归并排序。
5.3 个人踩过的一些坑和习惯用法
写这边文章的过程中，我复盘了一下自己从学生时代到工作这些年写排序算法踩过的坑，挑几个有共性的分享一下。
第一个坑是堆排序的"堆大小"被污染。我第一次手写堆排序时，总觉得"排序已经是最后阶段了，为什么还要传heapSize？反正数组长度不变。"结果排序结果乱七八糟，调试半天才发现交换到末尾的最大值又被重新调整回堆顶了。后来我养成了一个习惯：堆排序代码里所有涉及"堆大小"的地方，都注释清楚这是逻辑大小而不是数组长度。
第二个坑是选择排序的内层循环从i还是i+1开始。如果从i开始，那么minIndex初始值和扫描的第一个点重复，没有任何错误但多一次无意义的比较；如果从i+1开始，就必须保证minIndex初始化为i。我见过同事从i开始写然后minIndex初始化为i+1，导致最小值如果恰好在i位置时被忽略。
第三个坑是关于冒泡排序的提前终止。这个优化看似简单，但如果数组规模特别大且是纯倒序数据，提前终止永远不会触发，白白增加了一次"swapped"判断的开销。所以从性能角度说，提前终止优化不是免费的——它让"完全有序"场景更快，但让"完全逆序"场景略慢。到底用不用，取决于你对数据的预估。
我个人的习惯是：学习排序算法时用一种颜色标注"时间复杂度推导过程"，再用另一种颜色标注"稳定性分析"和"边界条件"这类容易被面试官追问的内容。把这些内容在代码旁边写成多行注释。虽然看起来啰嗦，但复习的时候效率极高。
5.4 延伸思考：从排序算法看懂算法设计思维
如果你把冒泡、选择、堆排序放在一起纵向比较，会发现一条非常清晰的算法设计脉络。
冒泡排序是一种"暴力美学"——把所有相邻元素都两两比较，靠大量交换达到有序。它的优点是逻辑极其简单，几乎零思维成本；缺点是效率最低，交换次数和比较次数都是O(n^2)。它的存在价值更多是作为算法入门的"hello world"。
选择排序展示了"分而治之"的雏形——每轮只解决一个位置的问题，把当前最小元素归位。它引入了"未排序区"和"已排序区"的概念，这个框架在后面更高级的排序算法里以不同形式反复出现。它的一个核心代价是"每次都需要全局扫描找最小值"，扫描成本居高不下。
堆排序就是对"每次需要全局扫描找最小值"这一痛点的精准打击：用堆这种数据结构把"找最小值"的成本从O(n)降到了O(log n)。整体复杂度从O(n^2)降到了O(n log n)。这个思维转化非常值得体会——与其反复扫描，不如用一个维护成本更低的数据结构来辅助决策。这种"用数据结构换算法效率"的思路，在后面的优先队列、并查集、图算法里面会反复遇到。
我在实际工作中发现，能把这三个算法连成一条线讲清楚的人，往往对算法和数据结构的理解都比较扎实。因为他不只是在背代码，而是理解了一个深层的逻辑：为什么冒泡慢？因为它做了太多无效比较和交换；为什么选择排序没有解决比较次数的问题？因为它在"找最小值"这一步仍然靠暴力扫描；为什么堆排序解决了？因为它把"找最小值"变成了一个可用数据结构高效维护的运算。
这个思考方式比单纯记住代码有价值得多。面试的时候，如果你能顺着这个逻辑讲出为什么会有冒泡到堆排的演进，面试官大概率会对你另眼相看。退一步说，即使不面试，在工作中需要设计一个频繁取最大值的组件时，你脑子里能第一时间跳出"大顶堆"这个方案，而不是去写一个for循环遍历找最大值，那就是学习这三种排序算法最大的收获。