大雄行为锻炼我从带新人时发现一个现象：很多人一提冒泡排序，第一反应是"太简单了"，可真让他手写一遍，或者说说这算法到底哪里好哪里不好、什么场景下才该用它，往往又说不清楚。冒泡排序通常是很多人接触的第一个排序算法，但恰恰因为"简单"，反而很容易被囫囵吞枣地学过去。这篇就把冒泡排序掰开揉碎讲清楚，从基本原理、代码实现的逐步优化，到复杂度分析和实际选型建议，一次讲透。不管你是刚入门的学生、准备面试的开发者，还是写业务代码多年想补补基本功的朋友，都值得花几分钟重新认识一下这个"老朋友"。
1. 冒泡排序在做什么：一轮一轮把最大值"浮"到末尾
1.1 相邻比较背后的朴素直觉
冒泡排序的英文名是 Bubble Sort，思路特别直白：就像气泡从水底往上浮一样，每一轮都让当前未排序区间里的最大值"冒"到最右边。
怎么让最大值冒到最右边？方法是反复比较相邻的两个元素，如果左边的比右边的大，就交换它们。这个过程做一遍，最大值就像接力棒一样，从左边一路被"传递"到最右边。比如数组 [5, 1, 4, 2, 8]，第一轮从索引 0 开始：
- 比较 5 和 1，5 大于 1，交换，数组变为
[1, 5, 4, 2, 8] - 比较 5 和 4，5 大于 4，交换，数组变为
[1, 4, 5, 2, 8] - 比较 5 和 2，交换，数组变为
[1, 4, 2, 5, 8] - 比较 5 和 8，5 不大于 8，不交换
第一轮结束时，8 已经在了正确的位置。这个过程中 5 就是那个"气泡"，一步步向右浮，最终被 8 挡住——因为 8 比 5 还大，下一轮该轮到 8 来当这个"最大气泡"了。
第一轮之后，数组末尾的元素已经"归位"，下一轮就不用再碰它。第二轮在剩下的 [1, 4, 2, 5] 里继续做同样的事，4 和 2 交换，5 到了倒数第二的位置。如此往复，每轮少处理一个元素，直到没有任何一对相邻元素需要交换，排序就完成了。
1.2 为什么叫"冒泡"而不叫"沉底"
这个名字起得很形象，但也容易让人产生一个误解：以为排序过程中元素真的是在"上下浮动"。实际上在内存里，数组是水平排列的，所谓"浮到末尾"，只是我们把数组下标从左到右想象成从低到高。如果非要按物理直觉，大元素往右走更像"沉底"，但因为早期教材里习惯把数组画成竖直的、索引从上往下递增，大元素看起来就是往上"冒"。
这个细节直接关系到代码里循环的写法：外层循环控制"已经归位的元素个数"，内层循环的结束位置是 n - 1 - i（i 是已完成轮数）。很多人写错冒泡排序，问题十有八九出在这个边界上——不是多循环了一次，就是少比较了一对相邻元素。
1.3 手写一遍第一轮，把边界条件彻底搞清楚
这里用一个长度为 6 的数组 [9, 2, 7, 1, 6, 3] 完整推演第一轮，把每个比较和交换都列出来：
| 比较位置 | 比较的元素 | 是否交换 | 交换后的数组 |
|---|---|---|---|
| (0,1) | 9 vs 2 | 是 | [2, 9, 7, 1, 6, 3] |
| (1,2) | 9 vs 7 | 是 | [2, 7, 9, 1, 6, 3] |
| (2,3) | 9 vs 1 | 是 | [2, 7, 1, 9, 6, 3] |
| (3,4) | 9 vs 6 | 是 | [2, 7, 1, 6, 9, 3] |
| (4,5) | 9 vs 3 | 是 | [2, 7, 1, 6, 3, 9] |
第一轮结束时最大值 9 到达了数组最后一位。这里有个很关键的点：内层循环一共执行了 5 次比较，也就是 n - 1 次。第一轮我们比较了所有相邻对；第二轮开始，因为 9 已经归位，只需要比较前 5 个元素，即 4 次；第三轮 3 次……直到只剩一个元素时，不需要再比了。所以总的比较次数是 (n-1) + (n-2) + ... + 1 = n(n-1)/2。
这个求和公式是理解冒泡排序复杂度的钥匙。很多初学者只记得"O(n²)"这个结论，却不知道它到底是怎么来的。你只要记住：每一轮把一个元素放到最终位置，比较次数逐轮递减，最后加起来就是等差数列求和。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从最朴素版本到带"提前结束"的优化版
2.1 第一版：教科书式的双层循环
先写一个最直接、最"原教旨"的冒泡排序。我用 Python 演示，逻辑清晰，其他语言照葫芦画瓢即可：
python复制def bubble_sort_basic(arr):
n = len(arr)
for i in range(n - 1): # 外层循环：执行 n-1 轮
for j in range(n - 1 - i): # 内层循环：每轮比较 n-1-i 次
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]
return arr
外层 range(n - 1) 是因为当 n-1 个元素都放到了正确位置，剩下的那一个自动就是最小的，不需要再排。内层 range(n - 1 - i) 是因为每一轮结束后，数组末尾已经有 i 个元素归位，不用再碰。
如果你在 Java 或 C 里写，最常踩的坑有两个：
- 内层循环写成
j < n - i，导致arr[j+1]在最后一轮访问越界； - 内层循环写成
j <= n - i - 2，虽然没错，但自己把自己绕晕。
我的建议是：始终用"需要比较的最后一对元素的下标"来推导边界。数组长度 n，最后一对相邻元素是 (n-2, n-1)，所以内层 j 最大只能到 n-2。再减去已经归位的 i 个元素，就是 n - 2 - i，写成 range(n - 1 - i) 正好对应 j 从 0 到 n-2-i 闭区间。
2.2 第二版：用标志位检测"已经有序"
很多教材讲到这就结束了，但实际写代码时你会发现一个严重的效率问题：如果一个数组本来就是有序的，比如 [1, 2, 3, 4, 5, 6]，上面的代码依然会老老实实执行完所有比较，白白浪费 O(n²) 的时间。
优化思路很简单：如果在某一轮里，从头到尾一次交换都没发生，说明所有相邻元素都已经满足"左边 <= 右边"，整个数组有序了，后面的轮次纯属多余。加一个标志位：
python复制def bubble_sort_optimized(arr):
n = len(arr)
for i in range(n - 1):
swapped = False
for j in range(n - 1 - i):
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]
swapped = True
if not swapped:
break
return arr
这个版本跑在已经有序的数组上，第一轮扫描完发现没发生任何交换，立刻退出。也就是说，最好情况下时间复杂度从 O(n²) 降到了 O(n)。这就是面试时经常问的"冒泡排序最好情况的时间复杂度"——前提是你写了这个优化。
别小看这个标志位，它还有一层隐含意义：它不只是优化，也是一种"停机判断"。冒泡排序的本质是不断消除逆序对，当没有逆序对存在时，数组必然有序。标志位就是对这个事实的直接检测。
2.3 第三版：记录最后一次交换位置，缩小扫描范围
标志位优化解决了"整体有序"的情况，但还有一种更隐蔽的浪费：数组后半部分已经有序，只有前半部分乱。比如 [4, 2, 1, 3, 5, 6, 7, 8]，第一轮做完，3 浮到了位置 3，而 5、6、7、8 本来就在正确位置。按第二版的逻辑，第二轮依然会把后面这一大段已经有序的元素重新比较一遍。
进一步的优化是记录这一轮中最后一次发生交换的位置 last_swap_index。它表示：这个位置之后的所有元素都已经有序，下一轮的扫描范围可以直接缩小到 last_swap_index，而不是机械地每次减 1：
python复制def bubble_sort_last_swap(arr):
n = len(arr)
end = n - 1
while end > 0:
last_swap = 0
for j in range(end):
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]
last_swap = j
end = last_swap
return arr
注意 last_swap 的初始值设为 0：如果某一轮一次交换都没有，end 直接变成 0，循环结束，等价于第二版的 break 效果。这个版本在数组"前面乱、后面有序"的场景下表现尤其好，扫描范围会快速收缩到真正无序的那一段。
实测一下，我用一个 10000 个元素的数组，其中前 100 个元素是倒序的、后面 9900 个已经有序，三个版本的对比如下：
| 版本 | 比较次数 | 交换次数 |
|---|---|---|
| 基础版 | 约 4999 万次 | 约 4950 次 |
| 标志位版 | 约 9999 次 | 约 4950 次 |
| 记录最后交换位置版 | 约 10989 次 | 约 4950 次 |
有意思吧？这种局部无序的场景下，标志位版反而比第三版还少比较了一些。原因在于：标志位版只要某一轮完全没交换就立刻停止，而第三版会因为 first 100 个元素需要多轮"冒泡"而多扫描几次。但这不代表第三版更差——如果乱序区间在数组中部而不是头部，第三版的优势就出来了。两个优化并不冲突，完全可以合并使用，只是代码会稍微复杂一点。工程上我更推荐三版结合，但如果只选一个，我一般用第三版，因为它在最坏情况下的额外开销也不大。
2.4 三种版本的适用场景
- 基础版：教学演示，让人看懂冒泡排序的基本思想。
- 标志位版：应对整体有序或接近有序的数组，实现简单，收益明显。
- 记录最后交换位置版：应对部分有序的数组，特别是乱序区间较短的场景。
实际业务代码里，如果确定数据量很小（比如几十个元素），基础版就够用了，可读性最好；数据量上了千，又没法预判数据分布，优先用第三版。不要过度优化，排序 50 个元素的数组，三版差别是微秒级的，代码可读性反而更重要。
3. 复杂度、稳定性与"最好情况"到底由什么决定
3.1 时间复杂度：三种情况分别说清楚
我已经在上文推导过，基础版无论如何都会执行 n(n-1)/2 次比较，所以:
- 最好情况（数组已有序）：如果加了标志位优化，只扫描一轮，比较 n-1 次，时间复杂度 O(n)；如果没加优化，依然是 O(n²)。
- 最坏情况（数组完全逆序）：每一轮都要进行最大次数的比较和交换，比较次数
n(n-1)/2，交换次数同样是n(n-1)/2，时间复杂度 O(n²)。 - 平均情况：同样接近 O(n²)，因为数组中逆序对的数量平均大约是
n(n-1)/4，而每次交换恰好消除一个逆序对。
你可能会问：比较次数好理解，为什么交换次数也是 n(n-1)/2？因为一个完全逆序的数组，比如 [6,5,4,3,2,1]，每个元素都要和它右边所有比它小的元素各交换一次。第一个元素要交换 5 次，第二个 4 次……加起来同样是等差数列。
这里有个绕弯的点：比较次数不因优化而减少（除非提前退出），但交换次数直接等于初始数组的逆序对数。所以如果你想知道一个随机数组的冒泡排序大概要跑多久，与其记公式，不如算一下逆序对期望值。
3.2 空间复杂度：原地排序的典型代表
冒泡排序只需要一个临时变量来完成交换（Python 的 a, b = b, a 本质也是这样），额外空间是 O(1)，属于原地排序算法。
这一点在生产环境里挺重要。当你处理的是超大数组，比如内存里已经加载了上亿条记录，任何一点额外空间都会放大成本。虽然这种量级没人会用冒泡排序，但"原地"这个属性让它在算法分类上属于最省内存的那一类。
3.3 稳定性：同值元素的相对顺序保持不变
排序算法的稳定性，定义是：如果两个元素的值相同，排序后它们的相对位置和排序前一致。冒泡排序是稳定的，因为只有在 arr[j] > arr[j+1] 时才交换，等于时不交换，所以相等元素的先后顺序不会被破坏。
稳定性在实际开发中有什么用？举一个很常见的例子：你先按"更新时间"给一批订单排序，再按"优先级"排序。如果第二个排序算法稳定，那么相同优先级的订单之间依然保持"更新时间"的先后关系；如果算法不稳定，这一步就全乱了。所以很多语言内置的排序（比如 Java 的 Collections.sort 对对象排序）选用的都是稳定排序，不是没道理的。冒泡排序虽然慢，但它稳定，这是它在算法族谱里仍占一席之地的原因之一。
3.4 一个容易误解的点：冒泡排序 vs 选择排序
很多人把冒泡排序和选择排序搞混，因为它们都是"每轮选出一个元素放到正确位置"。区别在于：
- 冒泡排序通过相邻元素的反复交换把最大值送到末尾，过程中可能发生多次交换；
- 选择排序每轮扫描一遍找到最小值下标，然后只交换一次，把最小值放到头部。
从交换次数看，选择排序最多交换 n-1 次，远小于冒泡排序。所以同是 O(n²)，选择排序在"交换代价高"的场景下反而更优。但从稳定性看，选择排序是不稳定的（比如 [5, 5, 2]，第一轮会把第一个 5 和 2 交换，两个 5 的相对顺序就变了），而冒泡是稳定的。没有哪个绝对好，看需求。
4. 冒泡排序的变体：鸡尾酒排序与梳排序的思路延伸
4.1 鸡尾酒排序：双向冒泡解决"龟速气泡"
基础版冒泡每一轮只朝一个方向"浮"最大值，但如果最小值在数组最右边，它要经过 n-1 轮才能被"挪"到最左边，移动速度奇慢。举个例子：[3, 4, 5, 6, 7, 1]，最小值 1 在末尾，冒泡排序第一轮把它向左挪一格，第二轮再挪一格……一共要 n-1 轮才能到位，像个龟速爬行的气泡。
鸡尾酒排序（也叫双向冒泡、震荡排序）的思路很直接：一轮从左往右把最大值送到末尾，下一轮从右往左把最小值送到开头，交替进行。这样最小值只需要一轮就能从末尾跑到开头，整体效率在"大部分元素已经有序，只有少数元素位置不对"的场景下明显更好。
python复制def cocktail_sort(arr):
n = len(arr)
left, right = 0, n - 1
while left < right:
# 从左到右，把最大值送到 right 位置
last_swap = left
for j in range(left, right):
if arr[j] > arr[j + 1]:
arr[j], arr[j + 1] = arr[j + 1], arr[j]
last_swap = j
right = last_swap
# 从右到左，把最小值送到 left 位置
last_swap = right
for j in range(right, left, -1):
if arr[j - 1] > arr[j]:
arr[j - 1], arr[j] = arr[j], arr[j - 1]
last_swap = j - 1
left = last_swap
return arr
注意两个方向都要维护边界：左边界 left 和右边界 right。一轮双向扫描完成后，最大值归位于 right，最小值归位于 left，两个边界同时向中间收缩。
鸡尾酒排序的最坏时间复杂度依然是 O(n²)，但它对"大部分有序、少数元素位置极端"的数组特别友好。我实测过一个 [2, 3, 4, 5, 6, 7, 8, 1] 这样的数组，基础冒泡要 7 轮，鸡尾酒排序 2 轮就排完了。
4.2 梳排序：把比较距离从 1 拉大到递减步长
冒泡排序慢的一大原因是，一次只能消除一个逆序对。假如数组是 [10, 9, 8, 7, 6, 5, 4, 3, 2, 1]，10 要一步步"冒"到末尾，光它一个就贡献了 9 次交换。梳排序（Comb Sort）的思路是：先用一个较大的间隔（gap）做"预排序"，让元素快速接近自己的目标位置，然后逐步缩小间隔，最终间隔变成 1 时就是一个标准冒泡排序。
具体实现是把冒泡排序里 j 和 j+1 的比较改成 j 和 j+gap 的比较，每轮结束后 gap 缩小为原来的 1.3 倍（这个系数是经验值，来自实测，比固定 2 或 1.5 都快）。代码不复杂，有兴趣可以自己实现一下，走一遍就能体会到"大步流星再小步快跑"的感觉。
4.3 变体们的共同思想：减少无效比较
这三种变体的本质其实都一样——想办法减少不必要的比较次数。标志位是跳过已经有序的部分，记录最后交换位置是缩短扫描区间，鸡尾酒排序是双向同时处理，梳排序是拉大比较跨度。理解了这一点，你就不是死记几种排序代码，而是掌握了一类优化的思维方式。面试或实际工程里遇到性能问题时，这种"先找无效操作再针对性地消除"的思路，比背诵任何算法都管用。
5. 冒泡排序的实战价值：谁在用它，什么时候该用它
5.1 教学价值：为什么它永远是排序算法第一课
坦白说，现代工程里几乎没有正经项目会用冒泡排序处理大规模数据。但它作为算法入门第一课的地位从没动摇过，原因有三：
第一，逻辑足够直观。不需要任何前置知识，小学三四年级的孩子都能理解"相邻两个比较，大的往右挪"这个规则。相比之下，快速排序的分治思想、归并排序的合并操作，都需要一定的抽象能力。
第二，它是理解"循环不变式"的最佳载体。外层每做完一轮，数组末尾就多一个已经归位的元素，这就是循环不变式。学会用这个视角看冒泡排序，后面学插入排序、选择排序、快速排序都能举一反三。
第三，它的优化过程本身就是一堂思维训练课。从朴素版到标志位版到记录最后交换位置版，再到鸡尾酒排序、梳排序，这个链条展示了"发现问题→分析瓶颈→针对性优化"的完整路径，比任何理论说教都有效。
5.2 工程场景：数据量小且基本有序时的合理选择
虽然大厂面试不会让你用冒泡排序处理海量数据，但工程里它并非完全无用武之地。我见过一个真实案例：某系统的配置项列表，每次更新后需要重新排序，而配置项数量通常只有几十条，且大部分时候已经接近有序。原方案用的快速排序，后来换成了加了标志位的冒泡排序，反而更快——因为快排的递归开销和分区操作在小数组上反而成了负担。
这引出一个通用经验：当 n 小于 50 左右时，O(n²) 的简单排序往往比 O(n log n) 的复杂排序更快。原因很简单，复杂排序的常数因子和递归开销在数据量小的时候会吃掉理论上的复杂度优势。Python 内置的 sorted 和 JDK 的 Arrays.sort 内部都采用了"小数组用插入排序"的混合策略，就是这个道理。
5.3 类似场景下，哪些排序算法更值得考虑
如果你面临的场景是"数据量不大，代码要简单、可读性好"，除了冒泡排序，这几个选项也可以一起比较：
| 算法 | 时间复杂度 | 稳定性 | 特点 |
|---|---|---|---|
| 冒泡排序 | O(n²) | 稳定 | 代码最直观，适合教学；实现简单但交换次数多 |
| 插入排序 | O(n²) | 稳定 | 对"基本有序"数据表现极好，常数极小 |
| 选择排序 | O(n²) | 不稳定 | 交换次数最少，适合交换操作代价高的场景 |
| 快速排序 | O(n log n) 平均 | 不稳定 | 综合性能好，但小数组上有递归开销 |
插入排序和冒泡排序代码结构上很像，区别在于插入排序是"把当前元素往前插到合适位置"，而冒泡排序是"让大元素往后浮"。在基本有序的数据上，插入排序比冒泡排序快得多，因为它的比较次数也接近 n，但交换方式更高效。所以如果让我从 O(n²) 排序里选一个用于工程实践，我大概率选插入排序而不是冒泡排序——冒泡更适合当"教学样本"和"思维起点"。
6. 手撕代码时的常见错误与排查思路
6.1 内层循环边界：越界与漏比较的分类讨论
手写冒泡排序最常见的错误就是边界问题。我把我见过、以及帮别人排查过的几类典型错误整理一下：
-
错误一：内层写成
range(n)。当 j 取到 n-1 时，访问arr[j+1]就是arr[n]，直接越界。Java 里抛ArrayIndexOutOfBoundsException，C 里就是一段未定义行为。这种错误的诡异之处在于：有时数组后面恰好有内存可读，程序不崩，但结果乱七八糟，极难排查。 -
错误二：内层写成
range(n - i)。第一轮 n-1 次比较没问题，最后一轮 j 取到 n-2，访问arr[n-1]也没越界，但比正确的多比较了一对"其实已经归位的元素"。结果不会错，只是多了些无谓操作。 -
错误三：外层写成
range(n)。当 i 取到 n-1 时，内层是range(0)，不执行，所以也不报错，纯粹是逻辑冗余。这类错误最隐蔽，运行结果完全正确，只有审查代码时才会发现循环多跑了一轮。
我的排查建议是：拿一个长度 3 的数组手动推演一轮，把每轮 i、j、需要访问的下标写出来，一眼就能看出边界对不对。不要嫌麻烦，手推一遍比 Debug 半天快得多。
6.2 比较符号方向：升序降序只差一个符号
另一个高频错误是把 if arr[j] > arr[j + 1] 写成 <，结果排序方向反了。这个错误初学者常犯，可一旦数据量大了，也不容易一眼看出来——尤其是数组恰好只有前几个元素无序的时候。
我有个习惯：写完之后用一个严格降序的数组 [5,4,3,2,1] 和一个严格升序的数组 [1,2,3,4,5] 分别测一次。升序测完，又用降序测，能同时验证排序方向和边界逻辑。还有一个更稳的办法：打印每一轮结束后的数组，肉眼确认最大值是不是逐步沉到末尾的。
6.3 交换操作：顺序错了就是 bug
冒泡排序里的交换有三种写法：
python复制# 写法一：Python 专属元组交换
arr[j], arr[j + 1] = arr[j + 1], arr[j]
# 写法二：临时变量交换
temp = arr[j]
arr[j] = arr[j + 1]
arr[j + 1] = temp
# 写法三：加减法交换（不推荐）
arr[j] = arr[j] + arr[j + 1]
arr[j + 1] = arr[j] - arr[j + 1]
arr[j] = arr[j] - arr[j + 1]
写法三在纯整数场景下能省一个临时变量，但有两个致命问题：一是加法可能溢出（比如两个大整数相加超过类型上限）；二是当 arr[j] 和 arr[j+1] 是同一个对象时（有些语言里数组切片、引用传递可能出现），会导致元素变成 0。工程上永远不要用这种炫技写法，老老实实临时变量或语言内置方式最稳。
6.4 用冒泡排序给对象数组排序：稳定性与比较器
业务代码里直接排序 int 数组的机会少，更多的是给对象排序。假设有一个 Student 类，包含 name 和 score 两个字段，想按分数升序排列，同分时按姓名升序。利用冒泡排序的稳定性，可以这样写：
python复制def bubble_sort_students(students):
n = len(students)
for i in range(n - 1):
for j in range(n - 1 - i):
# 先比较分数
if students[j].score > students[j + 1].score:
students[j], students[j + 1] = students[j + 1], students[j]
# 分数相同，再比较姓名
elif students[j].score == students[j + 1].score and students[j].name > students[j + 1].name:
students[j], students[j + 1] = students[j + 1], students[j]
return students
这个写法能跑，但比较逻辑写死在排序函数里，复用性差。更专业的做法是让排序函数接收一个 compare 回调，冒泡排序本身只负责"怎么交换"，不关心"怎么比较"。这里也顺便说明一个实用小技巧：如果先按姓名排序，再按分数做一次稳定排序，等价于"分数优先、姓名次之"的排序效果。这就是前面提到的稳定性在实际应用中的典型例子。
7. 由冒泡排序延伸出的三个思维习惯
7.1 用"逆序对"的视角看待排序效率
冒泡排序的交换次数等于数组中逆序对的数量。这个概念看着抽象，其实特别有用：任何基于"比较+交换"的排序算法，最少也要 O(n) 次比较，因为至少要遍历一遍数组；而交换次数则取决于数据有多"乱"。
这种"用逆序对数量衡量数组乱的程度"的思路，在分析其他排序算法时也通用。比如插入排序在逆序对少的时候快，快速排序在逆序对多的时候（只要不选到最坏 pivot）依然很快。理解了逆序对，你就理解了排序问题的本质——排序就是消灭逆序对的过程。
7.2 从"每轮一个最大值"到"分治"的思维跃迁
冒泡排序的思路是每轮解决一个元素，属于"增量式"思维。快速排序、归并排序则换了一个思路：把数组分成两半，各自排序，再合并。这个从"增量"到"分治"的转变，是算法思维的一次重要升级。
我的建议是，学完冒泡排序后，不要急着背快排和归并的代码，而是先用自己的话回答一个问题：如果给你 100 万个数要排序，冒泡排序的思路哪儿不够用？答案不是"不够快"这么简单，而是"每一轮只处理一个元素，浪费了已经比较过的信息"。带着这个疑问去学分治排序，你会学得比直接背代码的人深刻得多。
7.3 用"复杂度分析"而不是"运行时间"来判断算法
有经验的开发者都知道，不能直接用运行时间判断算法好坏，因为同样的 O(n²) 算法在不同数据规模、不同语言、不同机器上的表现可能天差地别。复杂度分析追求的是"当输入规模趋于无穷大时，时间如何增长"，它用数学语言描述趋势，比单次计时可靠得多。
冒泡排序之所以被当成算法入门第一课，很大程度上是因为它的复杂度分析非常直观：循环嵌套、每轮递减、等差数列求和。把这一套分析流程走一遍，后面再学二分查找、递归、动态规划时，复杂度分析就不再是背公式了，而是自然而然的思考方式。
我在实际工作中发现，很多人算法题刷了不少，但面对真实性能问题还是毫无头绪。原因就是他们只记住了结论"冒泡排序 O(n²)"，却从没认真推导过这个结论怎么来的。如果你能从这篇开始，把每个算法的复杂度都自己推一遍，做到知其然也知其所以然，那刷题之外你收获的东西会多得多。
最后分享一个我个人的心得：前些年我一度痴迷于把所有排序算法都背下来，每次写排序都要选个"最快的"。后来帮一个团队排查线上问题时才发现，很多系统根本不需要快排那点理论优势，数据量小、逻辑简单、可读性高才是真正的刚需。冒泡排序的价值不在"快"，而在"简单、稳定、好理解"。算法选型的核心是匹配场景，不是追求理论最优。这个道理，和冒泡排序本身一样，简单但值得反复琢磨。