选择排序与计数排序：原理、复杂度与工程选型实战解析

坦白说，排序算法学了这么多年，真正能在日常开发里随口说清实现细节的，反而往往是那几个“看着简单”的算法。选择排序和计数排序就是两个很有意思的代表：一个靠朴素的“每轮挑最小”走天下，一个靠“数清楚每个值出现了多少次”另辟蹊径。前者我经常拿来给新人讲“原地理清思路”，后者则是我在遇到特定范围数据时真正会考虑用到的工程方案。

这篇东西就基于我实际的调试过程来写，不做教科书式的罗列。我会把选择排序和计数排序的思路、写法、复杂度、稳定性、常用坑全部交代一遍，并用真实代码走通整个流程。适合刚学排序、准备面试复习，或者工作中突然想找一个“不用动脑的稳定排序方案”的同学。如果你能跟着代码敲一遍，收获会比只看一遍大很多。

1. 两种排序算法到底在解决什么问题

排序这件事，本质上是在回答“如何将一组元素按照某个规则重新排列”。选择排序和计数排序解决的问题是一样的，但思考角度完全不同：一个站在“位置”上看问题，一个站在“值”上看问题。

1.1 选择排序的思路是先锁定位置再找元素

玩过扑克牌理牌的朋友应该都有手感：把最小的一张牌放到最左边，然后从剩下的牌里再找最小的放到第二位，如此反复。选择排序就是这么干的。

选择排序的核心思想非常直白：先找到全数组最小的元素，把它和下标 0 的位置交换；再从下标 1 开始的区间里找最小元素，和下标 1 的位置交换；继续下去，直到整个数组有序。

这个过程中间没有“插入”和“腾位置”这种动作，只有两个步骤在循环：扫描区间找最小值，然后把最小值放到目标位置。所以每轮确认的只是位置，至于区间内其他元素的相对顺序如何被打乱，它其实完全不关心。

这个思路有个性格特点：它的交换次数非常少，每一轮最多只做一次交换。就算数组完全逆序，它也照样一轮只换一次。这一特点在数据元素本身很“重”的时候是有价值的，因为频繁交换大对象往往比比较更昂贵。

1.2 计数排序的思路是先数清楚每个值再铺回去

与选择排序逐个比较不同，计数排序试图绕开“比较”这种操作。它的出发点是：如果我就是知道每个数出现过多少次，那直接按从小到大的顺序把这些数铺回去不就行了吗？

比如数组 [2, 1, 2, 3, 1, 0]，值范围是 0 到 3。先数一数：0 出现 1 次，1 出现 2 次，2 出现 2 次，3 出现 1 次。这时候已经能还原出排好序的结果了：[0, 1, 1, 2, 2, 3]。整个过程中没做过任何一次元素之间的比较，靠的是一个“计数数组”。

但请注意，这种思路有一个明显的适用前提：数据必须是非负整数或可以被映射成非负整数，且取值范围不能过分散。计数排序的时间复杂度取决于数据范围 k，范围太大时它反而不划算。

1.3 两种思路的差异与应用场景

如果把排序算法按“是否基于比较”分类，选择排序属于典型的比较排序，计数排序则属于非比较排序。这个差异直接决定了它们的性能特征：

有没有发现，计数排序在某些场景下是可能做到 O(n) 级别时间的。这正是它迷人的地方：当一个问题的数据范围很集中时，理论上你是可以跑赢那些 O(n log n) 的“高级算法”的。但在数据范围非常稀疏的场景下，比如一亿个数里只有 0 和 99999999 两个值，k 就会大到离谱，计数排序瞬间变得不划算了。

理解选择排序和计数排序之间的这种互补关系，是我个人觉得排序入门阶段最重要的一件事。

2. 选择排序的完整拆解与实操实现

2.1 从思路到代码：如何一步一步写出正确的实现

选择排序的代码结构是一个双重循环，外层循环控制“我们要把位置 i 放上什么值”，内层循环负责“从 i 到末尾找最小值所在下标”。

下面我用 Python 写一个最基础版，这个版本是我平时给同事讲思路时用的：

python复制def selection_sort(arr):
    n = len(arr)
    for i in range(n - 1):
        min_index = i
        for j in range(i + 1, n):
            if arr[j] < arr[min_index]:
                min_index = j
        if min_index != i:
            arr[i], arr[min_index] = arr[min_index], arr[i]
    return arr

这里有个细节容易被忽略：外层循环只走到 n - 1。最后一个元素其实不需要再处理了，因为当前面 n-1 个位置都已经放上了正确元素时，剩下的那一个位置自然也就是正确的。

内层循环从 i + 1 开始找最小值下标，找到之后判断 min_index 是否等于 i。其实不判断也可以直接交换，因为 arr[i] 和自己交换没有任何副作用，只是多一次不必要的赋值操作。我习惯加上这层判断，除了语义更清晰，也能减少无意义的写操作。

拿数组 [5, 2, 9, 1, 7] 走一遍流程：

• 第一轮 i=0，在 [2, 9, 1, 7] 中找到最小值 1，下标为 3，交换 arr[0] 和 arr[3]，得到 [1, 2, 9, 5, 7]；
• 第二轮 i=1，在 [9, 5, 7] 中找到最小值 5，下标为 3，交换 arr[1] 和 arr[3]，得到 [1, 2, 5, 9, 7]；
• 第三轮 i=2，在 [9, 7] 中找到最小值 7，下标为 4，交换 arr[2] 和 arr[4]，得到 [1, 2, 5, 7, 9]；
• 第四轮 i=3，在 [9] 中最小值是 9，无需交换，排序完成。

这种手动走查在初学时特别有用，能真正理解“内层循环每轮只锁定一个位置”。

2.2 复杂度分析：为什么它总是 O(n²)

选择排序有个特征：比较次数是固定的，无论数组本来就接近有序还是完全逆序，它的内层循环一次都不会少跑。

第一轮比较 n-1 次，第二轮比较 n-2 次，一直到最后一轮比较 1 次。总比较次数是等差数列求和：

code复制(n-1) + (n-2) + ... + 1 = n(n-1)/2

所以时间复杂度的上界和下界都是 O(n²)。它不像插入排序，在最好情况下有 O(n) 的可能；选择排序就是“一视同仁”的慢性子，输入数据的初始有序程度对它影响不大。

空间方面，它只使用了一个临时变量用于交换，所以空间复杂度是 O(1)。这一点在实际工程中其实是它的核心竞争力之一，不需要额外内存就能完成排序。

关于稳定性，选择排序一般情况下是不稳定的。看一个例子：[5a, 3, 5b, 1]。第一轮会找到最小值 1 和下标 0 的 5a 交换，得到 [1, 3, 5b, 5a]。此时原本在前的 5a 被换到了 5b 后面，两个相等的 5 的相对顺序发生了改变。如果你有“同分数学生按姓名顺序排列”之类需求，直接用朴素选择排序就会踩到稳定性陷阱。

2.3 优化与变体：选择排序还有哪些可聊的点

选择排序在原理层面并不复杂，但工程上可以做不少优化。

第一个优化是每一轮同时找最小值和最大值。也就是从左往右找最小值放到开头，同时从右往左找最大值放到末尾。这样一轮可以固定两个位置，把外层循环次数减半。缺点是实现时边界处理要小心：如果最大值本身就在最左边，且最小值交换发生在最大值交换之前，位置就会打架。我在第一次写双向选择排序时就在这个边界栽过跟头，所以如果你要尝试，建议先在纸上推演一遍。

第二个变体是堆排序。堆排序是选择排序思想的延伸，它不再通过线性扫描来找最小值，而是通过堆这种数据结构在 O(log n) 时间内拿到最小值，从而把整体复杂度降到了 O(n log n)。所以如果你看懂了选择排序，理解堆排序的动机就会顺利得多。

第三个值得提的是针对“链表”实现的选择排序。选择排序在链表上实现很方便，因为它不依赖随机访问，只要有遍历能力就能完成。每个节点只需“找最小节点、摘下来、接到新链表末尾”，代码反而比数组还简单。在面试里偶尔会遇到这个变体，关键点是“断链”和“接链”的时机要处理准确。

3. 计数排序的完整拆解与实操实现

3.1 前置条件与算法流程

计数排序的应用场景比较明确：数据的取值范围 k 不大，并且最好知道最小值和最大值。如果你面对的是 0 到 100 分的考试成绩，那用计数排序非常合适；如果数据是 1000 个分布到 0 到 1 亿的随机数，那还是不要自找麻烦。

它的完整流程可以分成四步：

第一步，扫描原数组，找出最大值 max 和最小值 min。
第二步，根据最小值和最大值创建计数数组 count，长度是 max - min + 1。为什么不直接用 max+1 作为长度？因为如果数据从 100 到 200，直接用 max+1 长度是 201，实际上只有 100 个数的取值范围，白白浪费一半空间。
第三步，遍历原数组，每遇到一个值 v，就把 count[v - min] 加 1。
第四步，根据计数数组，把每个值按出现次数依次放回原数组。

我来写一个允许处理负数范围的基础版本：

python复制def counting_sort(arr):
    if not arr:
        return arr

    min_val = min(arr)
    max_val = max(arr)

    count_len = max_val - min_val + 1
    count = [0] * count_len

    for v in arr:
        count[v - min_val] += 1

    index = 0
    for i in range(count_len):
        while count[i] > 0:
            arr[index] = min_val + i
            index += 1
            count[i] -= 1

    return arr

这里面最核心的映射关系是 v - min_val。它保证任何整数都能映射到一个从 0 开始的非负下标。比如数据范围是 [-3, 0, 2]，min_val 是 -3，那么 0 就映射到下标 3，2 映射到下标 5，不会出现负数下标。

3.2 计数排序的稳定性与倒序填充技巧

上面的基础版本可以正确排序，但它是“不稳定”的，因为它在放回元素时只按值填充，完全不关心相同值的原始先后顺序。

如果只是“把数据排好序”，不稳定也没关系。但在很多实际项目里，我们排序的并不是数值本身，而是包含多个字段的对象。比如按成绩排序学生列表，如果两个学生成绩相同，我们希望保留他们在原数组里的先后顺序，这时候就需要一个稳定的计数排序。

实现稳定的办法是：把计数数组从“保存频次”改成“保存累计次数”，然后对原数组进行反向遍历，依次把每个元素放到它应该在的位置。

看看代码：

python复制def counting_sort_stable(arr):
    if not arr:
        return arr

    min_val = min(arr)
    max_val = max(arr)

    count = [0] * (max_val - min_val + 1)

    for v in arr:
        count[v - min_val] += 1

    # 将频次转换为累计次数
    for i in range(1, len(count)):
        count[i] += count[i - 1]

    output = [0] * len(arr)

    # 反向遍历原数组，保证稳定性
    for v in reversed(arr):
        idx = v - min_val
        count[idx] -= 1
        output[count[idx]] = v

    return output

为什么一定要反向遍历？举个例子：[2a, 1, 2b]。计数后 2 的累计次数是 3。正向遍历时，先处理 2a，把 2a 放到下标 2；再处理 2b 时，如果继续放到下标 2，就会把 2a 覆盖掉。反向遍历时，先处理最后一个 2b，把它放到下标 2，再处理 2a，把它放到下标 1。最后排序结果是 [1, 2a, 2b]，两个 2 的相对顺序和原数组一致，稳定性就保住了。

这个“累计次数减一后再放元素”的技巧本质上是在为每个值维护一个从后往前递减的“目标位置指针”，理解了这个指针机制，整个稳定版计数排序就再也没有死角了。

3.3 计数排序的边界情况与常见变形

实际使用计数器排序的时候，比起原理更麻烦的是各种边界情况。我来梳理一遍这些年我踩过的和常见的几类问题。

数据为空或只有一个元素

直接返回原数组就行，任何排序都这样。不过初学者容易在空数组上调用 min(arr) 报错，所以函数开头一定要做空值判断。

数据的值范围特别大

假设有 10 万个数，范围是 0 到 100 亿。这时候计数数组长度会超过 100 亿个整数。按每个整数 4 字节算，光 count 数组就要 400GB 内存，直接跑崩。这种场景不能硬上，要改思路，比如考虑基数排序或者桶排序，把大范围拆成多个小范围处理。

如何保存多种类型的数据

如果排序的对象是字典数组，比如按学生的 age 字段排序，我们需要把“值”和“原数组下标”关联起来。我的做法是单独构建一个“值与下标”的列表，或者用稳定计数排序时直接对原对象操作。更简单的思路是：先记录每个元素在原数组的下标，对下标数组做计数排序，最后通过下标重建对象数组。

计数排序与桶排序的关系

不少人会混淆计数排序和桶排序，实际上计数排序可以说是桶大小为 1 的特化版桶排序。桶排序是在每个桶内部继续排序，而计数排序直接把每个“桶”当成了一个计数位，不需要再做内部排序。理解了这层关系，看到计数排序的极端应用也就不会觉得困惑了。

4. 排序性能对比与实战选型参考

4.1 谁更快：从数据角度做实际验证

我在写一个内部工具时，遇到过需要频繁对一批 0 到 10000 之间的用户积分做排序的需求。数据规模大约 20 万条，更新频率很高。我担心计数排序的额外空间和变量构造太慢，就先做了个简单基准测试，在同样的数据下运行了三种排序。

测试结果大致是：对大随机数据，选择排序耗时是计数排序的几十倍以上；当 n 远大于 k 的时候，计数排序优势特别明显。但数据范围一旦拉到 1000 万，计数排序分配一个 1000 万长度的 count 数组本身就需要几十毫秒甚至更多，这时优势就没有 n=10000、k=100 的场景那么夸张了。

所以实战中最重要的一个判断标准是 n 和 k 的大小关系。如果 k 明显小于 n，计数排序几乎稳赢；如果 k 接近甚至大于 n，计数排序就会退化成一个“超级占内存的笨办法”。

4.2 选择排序到底该什么时候用

很多人学了快速排序、归并排序之后，就觉得选择排序没什么用了。我觉得这是认知上的误区。

选择排序最大的使用价值在于它几乎不使用额外内存，并且“交换次数”是 O(n) 级别的。当你处理的数据是某种极其宝贵的资源，比如不可变对象的引用、超大结构体的指针数组，交换代价很高的场景下，选择排序比插入排序和冒泡排序有优势。当然现在大部分语言对对象都用引用比较，这个优势更多体现在理论上，但在嵌入式或者 C 语言直接操作大 struct 数组的场景，依然成立。

还有一类场景是数据量特别小。比如排序 5 个以内的元素，选择排序和插入排序代码量少、不易出错，性能差异基本可以忽略不计。我在写一些一次性脚本时也会用选择排序，因为它不用引入复杂度，一眼看过去就知道在干什么。

4.3 计数排序在真实工程中的典型位置

计数排序最常见的工程应用，是作为底层辅助排序被其他算法调用。比如基数排序中，对每一位进行排序时，用的往往就是稳定版计数排序。因为基数排序本身要求“对每一位的排序都是稳定的”，而计数排序恰好能同时满足“稳定”和“线性时间复杂度”两个条件。

像等值范围数据的排名统计、直方图构建、像素颜色统计这类任务，本身就是计数行为，所谓排序只是其中一步。这时候直接上计数排序简直是降维打击，比各种基于比较的排序都省事。

再提一个我在实际业务里遇到过的问题：统计 1 万名员工的年龄分布，再按年龄从小到大输出名单。由于年龄范围只有 0 到 60 左右，用稳定计数排序一下子就能把同一年龄段的员工顺序保留下来，同时完成排序和分布统计。如果这里用快速排序，还得两次遍历：先统计分布，再排序，代码量反而更大。

5. 这两种算法中最容易出错的地方汇总

5.1 选择排序的三大高频翻车现场

第一个翻车点：内层循环从 i 开始而不是从 i + 1 开始。如果从 i 开始，min_index 会一直停留在初始位置，除非有更小的值被找到并更新。其实这并不影响最终结果，只是会多做一次无意义的自比较。但如果有人因此把 min_index 改成了 0，那就彻底错了，每一轮找最小值时会把前面已经排好的元素也纳入扫描，整个结果就乱了。

第二个翻车点：交换时没考虑下标相同导致“自交换”。大多数语言里自交换没问题，但在实现一些自定义对象的 swap 时，比如 C++ 的 swap 如果对自赋值处理不当，可能释放了内存又使用它。我见过有人在自己实现的结构体上通过三段式异或交换，恰好遇到同一地址，把值原地清零了，排查了一天才发现是自交换的问题。

第三个翻车点：认为它和插入排序是一回事。这两种算法的核心动作差很远：选择排序是“从剩余区间选出最小值并交换”，插入排序是“从已排序区间寻找合适位置并插入”。这个差别导致一个很微妙的性质：插入排序在数据近似有序时能够提前退出，选择排序不行。把它们混淆的人，写出来的代码很可能既不是选择排序也不是插入排序。

5.2 计数排序的边界处理与调试建议

计数排序最经典的问题非“负数处理”莫属。很多教科书上的版本都假设数据从 0 开始，导致写出来的代码遇到负数就崩溃。解决办法就是统一用 min 做偏移，把所有数映射到从 0 开始的下标区间。

第二个经典问题是 count 数组的长度。你要的是 max - min + 1，不是直接 max 也不是 max + 1。我第一次写的时候用 max+1 当长度，测试负数和包含 min 很大的数据时，要么越界要么浪费空间。所以建议在写完代码后，用一个包含负数、包含 0、包含重复值的数组做一轮单元测试，比如 [-5, 3, 0, 0, 3, -5, 2]。

第三个经典问题集中在稳定版实现。忘了反向遍历，或者反向遍历时忘了“先减一再用值当下标”，都会让元素覆盖并破坏稳定性。调试时可以在输出数组中标记每个元素原本的下标，检查同值元素的前后顺序。

5.3 排错技巧：用最小用例加断言来验证

我在给基础算法排错时最喜欢使用的方法，是构造一个极小的数据，比如长度为 4 的数组，包含两个重复的最小值，比如 [3, 1, 3, 2]。然后手动推演一遍目标排序结果，再在代码里加断言去验证每一步。

更直接的办法是拿 Python 的 sorted(arr) 当作“标准答案”，和自定义排序后的数组做全量比对，同时记录交换次数与稳定性，辅助判断问题出在哪一步。比如：

python复制arr = [3, 1, 3, 2]
sorted_expected = sorted(arr)

# 选择排序后
result = selection_sort(arr.copy())
assert result == sorted_expected, f"选择排序结果错误: {result}"

# 计数排序后
result2 = counting_sort_stable(arr.copy())
assert result2 == sorted_expected, f"计数排序结果错误: {result2}"

如果你还关心稳定性，就再构建一个二维数组，以第一个值为排序键，以第二个值为“原始顺序”索引，排序后检查同键元素的索引序列是否递增。这个方法我推荐给每一个想彻底搞懂稳定性的朋友。

6. 一个综合案例：如何用两种排序解决成绩排序问题

6.1 业务需求描述

假设现在有一个需求：给一个班级的学生按考试成绩从低到高排序，如果成绩一样，按照学号从小到大排列。学生人数大约是 1000 人，成绩范围 0 到 100 分。

这是一个非常典型的“稳定排序加多级排序”的需求。如果选用基于比较的稳定排序算法，比如归并排序或者插入排序的改良版，自然能一步到位。但今天我想演示的是：如何用选择排序先按学号排一次，再用稳定的计数排序按成绩排一次，达到“成绩为主、学号为辅”的最终顺序。这本质上就是一个基数排序思想的简化版。

6.2 代码实现与细节说明

我准备了一个简化版的学生类，只保留学号和成绩两个字段：

python复制class Student:
    def __init__(self, sid, score):
        self.sid = sid
        self.score = score

students = [
    Student(3, 85),
    Student(1, 92),
    Student(4, 85),
    Student(2, 78),
    Student(5, 92),
]

第一步，用选择排序按学号对列表原地排序。因为学号本身越小越靠前，这个排序是稳定无关紧要的，毕竟学号是唯一的。

python复制def sort_by_sid(students):
    n = len(students)
    for i in range(n - 1):
        min_idx = i
        for j in range(i + 1, n):
            if students[j].sid < students[min_idx].sid:
                min_idx = j
        if min_idx != i:
            students[i], students[min_idx] = students[min_idx], students[i]

第二步，用稳定版计数排序按成绩排序。成绩范围 0 到 100，所以最小值直接取 0，最大值直接取 100，可以固定创建长度为 101 的 count 数组，不需要动态求 min 和 max。

python复制def sort_by_score_stable(students):
    max_score = 100
    min_score = 0
    count = [0] * (max_score - min_score + 1)

    for s in students:
        count[s.score] += 1

    for i in range(1, len(count)):
        count[i] += count[i - 1]

    output = [None] * len(students)

    for s in reversed(students):
        count[s.score] -= 1
        output[count[s.score]] = s

    return output

执行时先调用 sort_by_sid(students)，再调用 sort_by_score_stable(students)，得到的结果中成绩升序排列，同分数的学生按学号升序排列。原理并不复杂：第二次排序是按成绩做的稳定排序，它不会改变同成绩学生在第一次排序中形成的学号顺序。这正好暗合基数排序的多轮稳定策略。

这里如果能亲手把这段代码跑起来并打印每个学生的学号和成绩，你会更清晰地感受到计数排序的稳定特性在实际需求中到底意味着什么。

7. 实践中的心得与补充建议

我自己在学习排序算法时，经历了很长一段“背代码”阶段，后来发现，真正让知识和代码内化的方式，是静下心来把每个算法的流程用笔画一遍，再对照代码看边界条件。

对于选择排序，我会建议大家重点理解“找到最小值后交换”这个动作背后的缺陷。当数据趋于有序时，选择排序依然固执地执行全部比较，这让它在大多数实战场景中不具备性能优势。但它的简单性和无误判风险，反而让它在排序小数据集或者对代码可读性要求高时成为一个不错选择。

对于计数排序，我认为它最值得学习的不是代码，而是“用统计替代比较”的思路转换。遇到数据范围受限的场景，我们首先要想到的是能不能用哈希、计数或者分桶来做，而不是一开始就套用通用排序器。这种“用空间换时间”的思路，在我的日常开发中不止一次帮助我从 O(n log n) 降到 O(n)，这才是计数排序带给我的最大价值。

最后提醒一点：算法理解和工程落地之间是有距离的。选择排序作为原地排序，数组版本和链表版本实现差异不小；计数排序作为非原地排序，对内存特别敏感的环境要谨慎使用。务必在真实代码里反复打磨，在测试用例里反复验证，这样以后再遇到类似的问题时，才能真正做到下意识选对算法。