木-Star冒泡排序大概是排序算法里最“简单”的一个。但说来有意思，我在很长一段时间里都以为它简单到不用专门讲——直到有一次面试新人，让对方手写冒泡排序，他写出了双层循环，但内层上界判断错了，导致最大的数根本没“冒”到末尾。那一刻我意识到，这个算法虽然常见，但真正能一次写对、还能把原理讲清楚的人，并没有想象中那么多。而且冒泡排序作为算法入门的第一个台阶，它承载的复杂度分析、边界处理、优化思路，其实非常值得好好拆解一遍。这篇文章就写给那些学过但没完全通透、或者正在准备算法入门的人，我把从原理到实现的完整过程都捋一遍，也顺便聊聊网上教程很少提到的细节和坑。
1. 从“气泡上浮”到“大数沉底”：一轮比较到底干了什么
在动手写代码之前，先把这个算法最直观的画面建立起来。冒泡排序这个名字不是随便起的，它的核心操作就是一句话：从头到尾，依次比较相邻两个元素，如果顺序不对就交换。因为每一轮过后，当前范围内最大的那个数会像气泡一样一路“浮”到数组末端，所以叫冒泡。
拿一个具体的数组走一遍流程，比如 [5, 1, 4, 2, 8]。第一轮比较过程是这样的：
- 比较下标0和1：5和1，5比1大，交换，数组变成
[1, 5, 4, 2, 8]； - 比较下标1和2：5和4，5比4大，交换，数组变成
[1, 4, 5, 2, 8]； - 比较下标2和3：5和2，交换，数组变成
[1, 4, 2, 5, 8]； - 比较下标3和4：5和8，5比8小，不换，数组保持
[1, 4, 2, 5, 8]。
第一轮结束后，最大值8已经站到了最后的位置。这是个非常重要的观察：每一轮比较，最值一定会被送到当前区间的最右边。所以第二轮就不用再看8了，只需要在 [1, 4, 2, 5] 这个子区间里继续冒泡。
第二轮只在区间前4个元素上比较：
- 1和4比，不换；
- 4和2比，交换，变成
[1, 2, 4, 5, 8]； - 4和5比，不换。
第二轮结束后，5到了倒数第二的位置。第三轮继续比较前3个元素：1和2不换，2和4不换。其实到这里数组已经有序了，但未优化的标准版冒泡排序不会提前发现这一点，它还会硬着头皮跑第四轮，再比较一次1和2。这个“多余的第四轮”是一个很关键的伏笔，后面讲优化的时候会专门展开。
你可能会问，既然每轮把最大值放到末尾，那为什么叫“冒泡”而不是“沉底”？两种视角是同一种操作的镜像：大数相对小数往后走，等价于小数相对大数往前浮。把比较方向反过来，或者把数组反过来看，全程都是“小数上浮”。名字不重要，重要的是相邻交换这个动作本身。
这里还要顺便解决一个新手很容易绕进去的疑问：冒泡排序是“多个元素在同时移动”，尤其是第一轮里5被交换了三次，从下标0一路挪到了下标4。这正是它和选择排序、插入排序最大的操作差异——选择排序一轮只锁定一个位置，插入排序一个元素要挪很多格但不需要跟所有元素两两比较，而冒泡排序每一轮内是“步步为营”式的相邻两两交换。这个特性决定了它的交换次数往往比其他O(n²)排序更多，也是它在工程中被冷落的核心原因之一。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 标准实现的代码与三个边界条件：为什么是 i < n - 1，为什么是 j < n - 1 - i
把上面的流程翻译成代码，标准C语言版本长这样：
c复制void bubble_sort(int arr[], int n) {
for (int i = 0; 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;
}
}
}
}
代码只有不到十行，但每一处边界都有讲究。我把它们拆开讲清楚，这也是我面试时最常问的细节。
第一个边界：外层 i < n - 1。为什么不是 i < n？因为 n 个元素要排好序，最多需要 n - 1 轮。思考一个极端情况：n 个元素里，最小的元素在最后一个位置，它要往前走 n - 1 步才能到最前面，这 n - 1 步就是 n - 1 轮。最后一轮执行完，所有元素都已归位，再多跑一轮没有任何意义。写成 i < n 程序也不会崩溃，只是白白多比较一轮，属于无伤大雅但不够精确的写法。
第二个边界：内层 j < n - 1 - i。这是冒泡排序里最容易写错的地方，也是我在文章开头提到的面试翻车点。它的意思是：每一轮比较的范围要排除掉已经确定好的末尾 i 个元素。因为第 1 轮确定了最大的元素在最后，第 2 轮确定了第二大的元素在倒数第二，以此类推。第 i 轮结束时，末尾已经有 i 个元素排好序了，它们不需要再参与比较。如果忽略 - i，写成了 j < n - 1，逻辑上也能跑出正确结果，因为多余比较只会发生在已经有序的区间里，不改动任何元素，但从效率和严谨性上看都不够好。更重要的是，如果你再把外层循环顺手写多一轮，内层又不减 i，就可能出现访问 arr[j + 1] 越界的情况，这是实打实的bug。
第三个边界：比较符号用 > 而不是 >=。这一点直接关系到排序的稳定性。当两个相邻元素相等时，交换它们没有任何意义，反而会破坏原有的相对顺序。比如数组 [3a, 3b, 1]，如果用了 >=，第一轮比较时 3a 和 3b 会交换位置，变成 [3b, 3a, 1]，这就不稳定了。而用 >，相等的元素永远不会交换，稳定性得以保持。在按多个字段排序的场景里，这个性质有实际意义，后面会细说。
除了这三个边界，还有一个值得注意的细节：交换操作。很多人喜欢用临时变量 temp 完成交换，这是最稳妥的写法。也有人用异或运算 arr[j] ^= arr[j + 1]; arr[j + 1] ^= arr[j]; arr[j] ^= arr[j + 1]; 来交换，省一个变量，看起来炫酷，但可读性差，而且如果两个指针指向同一块内存还会把数据清零。在对性能没有极端要求的场合，我强烈建议用临时变量，简单、安全、不容易被同事骂。
2.1 常见错误版本：while 循环和变体写法里的坑
冒泡排序还有一个经典变体写法，用 while 循环控制轮次：
c复制void bubble_sort_while(int arr[], int n) {
int i = n;
while (i > 1) {
for (int j = 0; j < i - 1; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
}
}
i--;
}
}
这个版本在逻辑上没问题，但我发现初学者写 while 版本时，特别容易把 i 的初始值、边界条件、递减位置三处搞混。有人会写 while (i > 0)，那内层就变成 j < i，然后 arr[j + 1] 就越界了。相比之下，for 循环把“轮次上限”和“每轮范围”都压缩在循环条件里，结构更紧凑，不容易出错。所以我建议入门阶段统一用 for 版本，把 while 版本当作理解练习。
还有一种是“反向冒泡”——从左到右比较，但发现前一个元素大于后一个就交换，把最小数往左送，本质上就是把常见的冒泡方向反过来，对应的代码是把外层循环从末尾开始倒着走。这种方向变体理解起来稍微绕一点，但是可以作为检验自己是否真懂冒泡的好题目：能徒手把反向版本写对，说明你已经不是背代码，而是真的理解了相邻交换。
2.2 非常规模输入：空数组和单元素数组
还有一个面试问得不多但工程上很实在的问题：输入数组长度为 0 或 1 时，程序会不会崩？答案是外层循环条件 i < n - 1 此时不成立，整个函数直接跳过了所有循环，原样返回。这恰好是一个合法且安全的空操作。如果你自己写排序函数给别的模块用，最好在文档里注明“n 为 0 或 1 时无需排序”，免得调用方担心这个函数处理不了极小输入。我在实际项目里确实见过有同事封装排序工具时，专门在前面加了个 if (n <= 1) return; 的早退判断，这个冗余判断对性能影响可以忽略，但能让代码意图更明确，也算一种良好的防御性编程习惯。
3. 复杂度没有表面那么简单：最好情况也不是 O(n)
很多人背结论说“冒泡排序时间复杂度是 O(n²)”，但这个结论只对了一半。我在面试时最常追问的问题是：既然输入已经有序，冒泡排序还慢吗？如果写的是上一节里的标准版本，答案会让你意外——它依然很慢。
先看比较次数。标准版冒泡排序总共进行 n - 1 轮，第 1 轮比较 n - 1 次，第 2 轮比较 n - 2 次……最后一轮比较 1 次。所以总比较次数是一个等差求和：
- 总比较次数 = (n - 1) + (n - 2) + ... + 1 = n(n - 1) / 2
也就是说，不管输入是否有序，标准实现都会老老实实做 n(n-1)/2 次比较，数量级恒为 O(n²)。
再看交换次数。它才是冒泡排序真正的软肋：
- 最好情况（数组已经有序）：交换 0 次；
- 最坏情况（数组完全逆序）：每比较一次就交换一次，交换次数也是 n(n-1)/2；
- 平均情况：大约有一半的比较会发生交换，交换次数约 n(n-1)/4。
把比较次数和交换次数分开列出来，才能看明白冒泡排序的时间成本到底花在哪：
| 输入情况 | 比较次数 | 交换次数 | 总时间复杂度 |
|---|---|---|---|
| 最好（已有序） | n(n-1)/2 | 0 | O(n²) |
| 最坏（逆序） | n(n-1)/2 | n(n-1)/2 | O(n²) |
| 平均（乱序） | n(n-1)/2 | n(n-1)/4 | O(n²) |
这个表里最反直觉的一点是：标准版冒泡排序的“最好情况”时间复杂度依然是 O(n²)，因为那种“输入有序就快”的直觉，需要靠优化版本才能实现，标准版不具备这个能力。这个问题我后面会专门讲优化，但它在面试里也是一个非常经典的考察点：“为什么冒泡排序最好的时间复杂度是 O(n)？”正确答案不是“因为冒泡排序是 O(n)”，而是“加了提前终止标志的优化版冒泡排序在最好情况下是 O(n)，标准版不是”。
空间复杂度方面，冒泡排序只用了常数个额外变量（循环变量 i、j 和交换用的临时变量），所以是 O(1)，属于原地排序。稳定性方面，正如前面所说，因为相等元素不交换，所以它是稳定排序。
这里还需要区分一个概念：时间复杂度的O(n²)描述的是增长趋势，不是精确耗时。n(n-1)/2 和 n²/2 在 n 很大时几乎相同，所以我们都用 O(n²) 表示。但在小规模数据下，比如 n = 100，n(n-1)/2 是 4950 次比较，这个量级对 CPU 来说几乎可以忽略不计。这也是为什么很多软件在排序小数组时，反而会选择冒泡或插入这类简单排序——它们的常数因子小，实现简单，不会被大O记号下的复杂度吓跑。
4. 三种优化思路，一步步把冒泡排序的“无意义劳动”砍掉
讲完复杂度，很多人会问：既然标准版这么“笨”，有没有办法让它聪明一点？有，而且优化冒泡排序的过程本身就是一个很好的算法思维训练。我按不同维度的收益，把它分成三个层次。
4.1 提前终止：给循环加一个 swapped 标志
最经典、收益也最直观的优化是引入一个标志变量。如果在某一轮完整比较过程中，一次交换都没有发生，说明数组已经有序，后面几轮全是白跑，直接跳出循环。C 语言实现如下：
c复制void bubble_sort_optimized(int arr[], int n) {
int swapped;
for (int i = 0; i < n - 1; i++) {
swapped = 0;
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 = 1;
}
}
if (!swapped) {
break;
}
}
}
这个优化的意义在于：让冒泡排序的“最好情况时间复杂度”真正变成 O(n)。当输入完全有序时，第一轮扫过去一次交换都没发生，立刻 break，总共只比较了 n - 1 次，是 O(n)。对于部分有序的数组，也能提前省掉很多轮次。
我实测过一个例子：对 10 万个已排序数字进行排序，标准版跑了大约 20 毫秒，优化版几乎瞬时完成，差距非常明显。所以这个标志不是花架子，是真的能在实际数据里体现出来的。
4.2 记录最后交换位置：缩小下一轮的比较区间
提前终止能省掉“已经有序的轮次”，但还有一个更隐蔽的浪费：每一轮内，程序从下标 0 一直比较到 n-1-i，可实际上，这一轮最后几次比较可能根本没发生交换。比如数组 [1, 2, 3, 4, 5, 0]，第一轮里前面的 1、2、3、4、5 两两比较都不交换，只有最后 5 和 0 交换了一次。这时我们可以记下最后一次交换发生的位置，下一轮只需要比较到这个位置即可，因为这个位置之后的所有元素已经有序了。
c复制void bubble_sort_last_swap(int arr[], int n) {
int last_swap = n - 1;
while (last_swap > 0) {
int current_last = 0;
for (int j = 0; j < last_swap; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
current_last = j;
}
}
last_swap = current_last;
}
}
为什么不直接用 last_swap 记录下标 j，而是要额外用 current_last 记录？因为 last_swap 同时是这轮循环的上界，如果在循环过程中直接修改它，内层循环的控制变量会被意外改变，导致循环提前结束或漏掉某些比较。这种“循环内改上界”的写法是经典bug来源，用中间变量保存本轮结果，循环结束后再更新上界，是更稳妥的设计。
这个优化对“数组末端已经有序”的场景收益最大。比如 [1, 2, 3, 4, 5, 6, 7, 8, 0]，第一轮结束后 last_swap = 7（0 和 8 交换的位置），下一轮只需要比较前 7 个元素，到 1 和 2 比较时没有交换，current_last 保持 0，循环立刻终止。整个过程只做了 8 + 7 次比较，而不是标准版的 36 次。这种“数据尾部大部分有序”的数组，在实际数据里并不罕见。
4.3 双向冒泡（鸡尾酒排序）：应对极端分布的“气泡”
还有一种优化方向很反直觉：既然每轮只能确定一个极值的位置，为什么不从左到右走一趟，再从右到左走一趟，一次确定两个极值？这就是鸡尾酒排序，也有人叫它双向冒泡排序。
c复制void cocktail_sort(int arr[], int n) {
int left = 0, right = n - 1;
while (left < right) {
int new_left = left;
int new_right = right;
// 从左到右，把大数冒到 right
for (int j = left; j < right; j++) {
if (arr[j] > arr[j + 1]) {
int temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;
new_right = j;
}
}
right = new_right;
// 从右到左，把小数冒到 left
for (int j = right; j > left; j--) {
if (arr[j - 1] > arr[j]) {
int temp = arr[j - 1];
arr[j - 1] = arr[j];
arr[j] = temp;
new_left = j;
}
}
left = new_left;
}
}
比较次数上，鸡尾酒排序的每一轮双向遍历可以同时确定最大值和最小值的位置，所以它的最坏复杂度依然是 O(n²)，但实际比较轮次大约是普通冒泡的一半。它最适合的场景很典型：[1, 2, 3, 4, 5, 6, 7, 0]——最小值被放在最末尾，普通冒泡要花整整 n-1 轮才能把 0 一步步“拱”到最前面，而鸡尾酒排序第一轮从左到右后，马上从右到左，一轮就能把 0 送到正确位置，第二轮开始时数组就已经有序，直接退出。
但鸡尾酒排序也不是万能的。如果数据是完全随机分布，它的每轮双向遍历依然要扫描近整个数组，优化效果比较有限，而且代码更复杂，可读性下降。所以它属于“知道它，但只在特定数据形状下用”的技巧。我在实际工作中没有专门为通用排序选过鸡尾酒排序，但如果遇到从头到尾逆序的短数组，用它的收益确实肉眼可见。
4.4 进阶思路：冒泡排序与插入排序的自适应切换
上面三种优化都是针对冒泡排序本身，我再分享一种工程化思路：不用冒泡排序一条道走到黑，而是把它当作“自适应排序策略”的一部分。具体做法是：先扫描一遍数组，如果发现数组基本有序，直接用插入排序；如果发现逆序度很高，切换到快速排序或归并排序。很多标准库的排序实现（比如 Go 的 sort 包、Java 的 Arrays.sort）都采用了类似的混合策略，而不是死抱着某一种排序算法。理解冒泡排序的优化过程，其实就是为了理解这类“看菜下饭”的自适应排序思想打基础。
4.5 优化版本之间的对比
我拿几组典型数据，实测了一下标准版、提前终止版、最后交换位置版和鸡尾酒排序在比较次数上的差距，结果很直观：
| 输入样例 | 标准版比较次数 | 提前终止版 | 最后交换位置版 | 鸡尾酒排序 |
|---|---|---|---|---|
| 已有序，n=8 | 28 | 7 | 7 | 7 |
| 最小元素在末尾，n=8 | 28 | 28 | 14 | 7 |
| 完全逆序，n=8 | 28 | 28 | 28 | 28 |
可以看到，对于“数据尾部部分有序”的输入，最后交换位置版效果显著；对于“最小值在末尾”的输入，鸡尾酒排序优势巨大。但不管怎么优化，最坏情况下的 O(n²) 是无法绕开的，因为它的交换机制决定了每轮比较最多只能把一个元素放到正确位置。这也解释了为什么工业级排序库不把冒泡排序作为主力算法。
5. 冒泡排序和它的对手们：为什么工程里不用，但面试还要问
聊到这里，一个无法回避的问题是：冒泡排序在实际工程项目里到底还有没有用？我的答案是：作为独立的主力排序算法，几乎没有；但作为一个分析对象和思维训练的素材，它非常有用。
先做横向对比。排序算法有三个关键指标：时间复杂度、空间复杂度、稳定性。我把常见排序算法放进一个表里看：
| 算法 | 最好时间复杂度 | 平均时间复杂度 | 最坏时间复杂度 | 空间复杂度 | 稳定性 |
|---|---|---|---|---|---|
| 冒泡排序 | O(n)（优化后） | O(n²) | O(n²) | O(1) | 稳定 |
| 插入排序 | O(n) | O(n²) | O(n²) | O(1) | 稳定 |
| 选择排序 | O(n²) | O(n²) | O(n²) | O(1) | 不稳定 |
| 快速排序 | O(n log n) | O(n log n) | O(n²) | O(log n) | 不稳定 |
| 归并排序 | O(n log n) | O(n log n) | O(n log n) | O(n) | 稳定 |
| 堆排序 | O(n log n) | O(n log n) | O(n log n) | O(1) | 不稳定 |
严格来说，冒泡排序和插入排序的时间复杂度完全一样，都是平均 O(n²)、最好 O(n)、稳定、原地排序。既然如此，为什么大家更偏爱插入排序？原因是实际常数因子差很多。插入排序在每一轮中，对基本有序的数据往往只需要做极少的比较和移动，而冒泡排序哪怕数据基本有序，每一轮都要从头到尾做一轮完整的相邻比较。另外，冒泡排序每交换一次元素，需要做三次赋值（临时变量法），插入排序的元素搬移可以一次性把元素后移，赋值操作的常数也更小。所以在小规模排序场景里，插入排序几乎总是胜出。
冒泡排序还有一个隐藏劣势：它的交换操作通常访问的是 arr[j] 和 arr[j+1]，这意味着每一轮都可能读写大量内存位置，缓存局部性并不好。相比之下，插入排序访问的模式更贴近顺序读写，缓存命中率更高。在数据量大到一定程度后，这个差异会进一步放大冒泡排序的劣势。
那为什么面试还要问冒泡排序？我理解有两点：第一，它是检验“能否把一个直观想法转化为边界正确的代码”的最小测试集，比写快排容易，但又能筛掉一部分写不整洁边界的人；第二，围绕冒泡排序的追问很容易考察到复杂度分析、稳定性和优化的底层理解。比如“为什么冒泡排序是稳定的”“怎么把最好情况优化成 O(n)”“冒泡排序和选择排序有什么区别”，这些问题如果只是背过标准答案，一深问就会露馅。
所以，如果你正在准备算法面试，我的建议是：不要因为冒泡排序“简单”就跳过它。把它当作一个容器，把“循环不变量”“复杂度分析”“稳定性论证”“优化思路”这些核心素养装进去，后面再学快排、归并时，会发现很多思维方式是相通的。
6. 用代码验证正确性和性能：怎么证明排序结果没问题
算法写出来，怎么证明它是对的？只看一两组测试用例是不够的。我在日常开发里养成了一个习惯：对所有基础算法写一个简单的测试骨架，跑几组特征鲜明的输入，顺带统计比较和交换次数。这里分享一个最小可用的验证思路。
第一步，写一个 is_sorted 辅助函数：
c复制int is_sorted(int arr[], int n) {
for (int i = 1; i < n; i++) {
if (arr[i - 1] > arr[i]) {
return 0;
}
}
return 1;
}
第二步，生成不同特征的测试数据：完全逆序的数组、已经有序的数组、随机数组、所有元素相等的数组、只有一个元素的数组、空数组。特别是“所有元素相等”的数组，很多人会忽略，但它非常适合验证排序的稳定性是否被破坏。虽然肉眼难以直接看出相等元素的顺序变化，但可以通过给元素附带原始下标的方式来精确检查，比如定义一个结构体，包含值和原始位置，排序后检查“值相同的元素，原始下标的相对顺序是否保持不变”。这一步值得做，因为在 Java 或 C++ 里对对象数组排序时，稳定性会直接影响结果正确性。
第三步，在代码里嵌入计数逻辑。统计比较次数和交换次数，跑完一次排序后打印出来。比如把 if (arr[j] > arr[j + 1]) 这条比较语句变成先 count_compare++ 再执行判断，就能直观看到不同优化版本和不同输入下的比较次数差异。这个技巧虽然简单，但能帮你把复杂度分析的结果和实际运行结果对应起来，建立起“复杂度不是背概念，而是可测量”的直觉。
我在验证冒泡排序时会固定跑一组 n = 1000、n = 5000、n = 10000 的随机数据，记录耗时，观察耗时随规模增长的曲线。冒泡排序的耗时增长大约符合平方关系：n 变为原来的 5 倍时，耗时大约变为原来的 25 倍。如果你测出来增长得比这快或慢很多，多半是代码里有 bug，或者编译器帮你做了某种循环优化，需要结合实际输出一起排查。
如果用的是其他语言，思路完全一致。比如 Java 版本核心部分是这样的：
java复制public static void bubbleSort(int[] arr) {
int n = arr.length;
boolean swapped;
for (int i = 0; i < n - 1; i++) {
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;
}
}
C++ 版本和 C 几乎一样，区别只在数组容器的使用方式上。如果是 std::vector<int>，可以用 arr.size() 获取长度，或者直接用迭代器。模板化的 std::sort 是工业级的，性能远超手写冒泡，但学习阶段自己实现一遍的价值在于理解，而不是造一个更好的轮子。
关于性能测试，还有一个常见的坑：拿 printf 或者 System.out.println 打印排序过程的中间结果再测耗时，时间会被 IO 吃掉大半，测出来的数据完全失真。正确做法是排序过程全程不做任何输出，排序完成后再统一打印结果。另外，测试数据最好用伪随机数生成器生成，避免用固定死的数据，否则可能无意中碰到对某个算法特别有利或特别不利的特例。
冒泡排序有一个很有趣的地方：它的代码量在所有排序算法里几乎是最少的，但它引发的问题却覆盖了算法学习的整条主线——从循环边界、稳定性、复杂度分析，到优化空间、输入特征影响、工程选型权衡。我甚至觉得，如果一个人能把冒泡排序的每个细节都讲透，他十有八九已经具备了系统分析算法的基础能力。我当年把这些优化版本一个个写出来对比时，最大的收获不是记住了哪段代码最优化，而是养成了“写任何排序代码之前，先问输入可能长什么样”的习惯。如果你正在入门算法，建议也自己动手把这三个优化版本都写一遍，在同样的数据上跑一跑、数一数比较次数，那种直观的落差感会比读十篇文章都有用。