堆排序从入门到实战：原理、C++实现与优先队列应用

我整理算法笔记的时候，把堆排序放在清单第13个位置。前面那些排序写起来再别扭，思路也基本是“线性”的，唯独堆排序，我第一次亲手实现的时候硬是调出了数组越界，后来查了半小时才发现自己把“数组从0开始”和“数组从1开始”的父子节点公式混着用了。这种问题不亲自踩一次，光看原理根本意识不到。

堆排序这个主题，适合三类人反复读：准备算法面试的开发者、工作中要手写优先队列或TopK方案的工程师、还有正在学数据结构但总觉得“堆”很抽象的学生。它解决的核心问题其实不只是“排序”，而是一种动态维护最大值或最小值的能力。这篇文章我会从底层的完全二叉树讲起，把建堆、调整、排序三个阶段拆开揉碎，再附上C++实现、复杂度推导和常见错误排查，尽量让你看完就能直接写出正确版本，也能用它去解一堆看起来和排序无关的题。

1. 堆排序的底层结构：为什么它不需要一棵真的“树”

1.1 从完全二叉树到数组，存储方式决定了实现难度

堆排序的前提是二叉堆，而二叉堆的第一原则是：它一定是一棵完全二叉树。什么叫完全二叉树？简单说就是每一层都从左到右紧密排列，除了最后一层可以不满，其他层必须填满，而且最后一层的节点也都要靠左。

为什么要强调完全二叉树？因为它能直接用数组存，不需要指针、不需要额外的树节点结构。你只要知道当前节点在数组里的下标 i，就能算出来它的左孩子在下标 2i+1，右孩子在下标 2i+2，父节点在下标 (i-1)/2。这套公式是堆排序所有代码的地基，很多人后面写错，不是逻辑错，是下标从0开始还是从1开始没统一。

如果你习惯从1开始计数，左孩子是 2i，右孩子是 2i+1，父节点是 i/2。这两种体系单独用都没问题，但最怕混用。我见过有人一遍写 2i，一遍又写 2i+2，结果数组越界还查不出来。我的建议是：在 C++、Java、Python 这些主流语言里，一律按数组下标从0开始记，也就是左孩子 2i+1，右孩子 2i+2，父节点 (i-1)/2，全篇统一，别给自己挖坑。

数组能表示堆的另一个好处是空间复杂度是 O(1)。堆排序只会在原数组上做交换和调整，不像归并排序那样需要一个同等大小的临时数组，这一点在高内存敏感的场景里很有用。

1.2 大顶堆和小顶堆怎么选，堆排序默认用大顶堆的真相

堆分两种形态：大顶堆，父节点永远不小于孩子节点，堆顶是最大值；小顶堆，父节点永远不大于孩子节点，堆顶是最小值。

很多人第一次接触堆排序时有个疑惑：如果我要升序排序，是不是应该用小顶堆，把最小值一个个取出来更自然？听起来没毛病，但真要实现起来会很别扭。原因在于你取走堆顶最小元素后，剩下的元素仍然需要“补位”和“重排”，你取出来的最小值放到哪里去？放到一个新数组里的话，空间复杂度就变成 O(n) 了，这就不符合原地排序的初衷。

堆排序的设计非常巧妙：它用大顶堆做升序排列。第一轮建堆后，最大的元素已经在堆顶，也就是数组下标0的位置。此时把堆顶元素和当前堆的最后一个元素交换，最大的元素就跑到数组末尾了，它已经处于最终位置。接着把“堆的有效长度”减一，再对剩下的部分重新调整堆结构，让新的堆顶变成剩余元素里的最大值，再交换到倒数第二个位置。如此循环，数组从后往前逐步变成有序。

大顶堆配合“交换到末尾”的思路，正是堆排序能原地完成的精髓。你不需要额外开空间，也不需要把最大值移来移去，每次只要交换一次，再做一次堆调整就行。

2. 堆的两个核心操作：上浮与下沉，谁才是堆排序的发动机

2.1 下沉操作是堆排序的核心，理解它你就掌握了八成

堆的调整方式有两种：上浮和下沉。上浮一般出现在往堆里插入新元素的时候，新元素先放到数组末尾，然后不断和父节点比较，如果比父节点大就交换，一路往上走。下沉则相反，某个节点如果比它的孩子节点小，就和较大的孩子交换，一路往下走。

堆排序全程几乎只需要下沉。为什么？因为排序阶段的每次交换都会把一个相对较小的元素送到堆顶，比如把末尾元素换上来之后，这个元素大概率不满足大顶堆的约束，需要把它从堆顶往下“沉”到合适的位置。另外，建堆过程本质上也是对每个非叶子节点做一次自顶向下的下沉调整。

下沉的代码逻辑里有一个很关键的点：每次找当前节点和它的左右孩子中最大的那个，如果最大的不是当前节点，就交换，然后继续往下处理被交换过去的孩子位置。如果当前节点已经是三个里最大的，循环就可以终止了。

下沉有一个隐藏细节：右孩子不一定存在。当 n 是偶数或者当前节点在堆的倒数第二层时，右孩子的下标可能刚好等于堆长度，访问时就会越界。所以判断孩子时必须加一个条件，确保 l < n、r < n 才比较。这个细节单独看很简单，但在写递归版本时容易漏。

2.2 为什么建堆时从 n/2-1 开始，而不是从数组末尾开始

建堆阶段新手最容易问的问题就是：为什么循环是 for (int i = n/2 - 1; i >= 0; i--)？为什么不从 n-1 开始、也不从0开始？

答案和叶子节点有关。在完全二叉树里，叶子节点没有孩子，它们自身天然满足堆的性质，不需要调整。只有非叶子节点才可能破坏堆结构。第一个非叶子节点在哪里？最后一个有孩子的节点，它的下标是 n/2 - 1。这个结论在数组从0开始下标时成立，如果数组从1开始，就是 n/2。

举个例子：数组长度 n=6，最后一个节点下标是5，下标5的父节点是 (5-1)/2 = 2，所以第一个需要调整的非叶子节点是下标2。此时 n/2 - 1 = 3-1 =2，正好吻合。下标2之后的节点都是叶子，调整它们没有任何意义。

从后往前调整还有一个深层原因：堆的性质会向上传递。如果你从堆顶开始向下调整，此时下面的子树可能还不是堆，调整结果不保证正确。但如果你从最后一个非叶子节点开始，一层层往上调整，每调整一个节点时，它的左右子树都已经满足堆的结构了，这时只需要把这个节点下沉到正确位置，整棵子树就变成堆。这种顺序看起来简单，却是整个建堆过程正确的基石。

3. 完整实现堆排序：建堆、交换、再调整，缺一不可

3.1 一份可以直接运行的 C++ 实现

先把整体代码放上来，后面我会拆开逐步解释。这段代码我按数组下标从0开始的方式编写，比较符合现在主流语言的习惯。

cpp复制#include <vector>
#include <iostream>
using namespace std;

void siftDown(vector<int>& a, int n, int i) {
    while (true) {
        int largest = i;
        int left = 2 * i + 1;
        int right = 2 * i + 2;

        if (left < n && a[left] > a[largest]) {
            largest = left;
        }
        if (right < n && a[right] > a[largest]) {
            largest = right;
        }
        if (largest == i) {
            break;
        }
        swap(a[i], a[largest]);
        i = largest;
    }
}

void heapSort(vector<int>& a) {
    int n = (int)a.size();

    // 阶段一：建堆
    for (int i = n / 2 - 1; i >= 0; --i) {
        siftDown(a, n, i);
    }

    // 阶段二：排序
    for (int i = n - 1; i > 0; --i) {
        swap(a[0], a[i]);
        siftDown(a, i, 0);
    }
}

int main() {
    vector<int> arr = {4, 10, 3, 5, 1};
    heapSort(arr);
    for (int x : arr) {
        cout << x << " ";
    }
    cout << endl;
    return 0;
}

这段代码的输出是 1 3 4 5 10。我建议你把这段代码亲手敲一遍，不要复制，因为堆排序的很多下标细节只有自己敲过才记得住。

3.2 建堆阶段：数组从无序到满足大顶堆约束

我用刚才的例子手动跑一遍建堆过程，看看到底发生了什么。

初始数组是 [4, 10, 3, 5, 1]，n=5，第一个非叶子节点下标是 5/2 - 1 = 1。

先调整下标1，也就是值10。它的左孩子是下标3，值5；右孩子是下标4，值1。10本身已经是最大的，所以不需要动。

接着调整下标0，值4。它的左孩子是下标1，值10；右孩子是下标2，值3。三个节点里最大的是10，所以把4和10交换，数组变成 [10, 4, 3, 5, 1]。下沉还没结束，因为4现在到了下标1，需要继续看它的孩子。下标1的左孩子是下标3，值5；右孩子是下标4，值1。最大的是5，于是把4和5交换，数组变成 [10, 5, 3, 4, 1]。此时4到了下标3，下标3已经是叶子节点，下沉终止。

建堆完成后，数组是大顶堆形态，堆顶是10。

这一步有个值得注意的点：我为什么在第一轮只调用了两次 siftDown？因为一共5个元素，非叶子节点只有下标0和下标1两个。堆调整的数量并不是和 n 成正比调到每个元素，而是只处理非叶子节点。这也是很多人读代码时容易困惑的地方。

3.3 排序阶段：每次把最大值换到堆的末尾

建堆完成后进入排序循环。此时堆的有效范围是整数组，长度5。

第一轮：把堆顶10和下标4的1交换，数组变成 [1, 5, 3, 4, 10]。此时10已经到达最终位置，后面的循环不再管它。接着对前4个元素做下沉，调整下标0。1的孩子是5和3，最大的是5，交换后数组变成 [5, 1, 3, 4, 10]。然后1继续下沉到下标1，它的左孩子是下标3的4，4比1大，交换，得到 [5, 4, 3, 1, 10]。第一轮结束，堆的有效范围变成前4个，堆顶是5。

第二轮：把5和当前堆末尾的下标3的1交换，数组变成 [1, 4, 3, 5, 10]。对前3个元素做下沉，1和4交换，得到 [4, 1, 3, 5, 10]。堆有效范围变成前3个。

第三轮：把4和下标2的3交换，数组变成 [3, 1, 4, 5, 10]。调整前2个元素，1不需要动。堆有效范围变成前2个。

第四轮：把3和1交换，得到 [1, 3, 4, 5, 10]。

严格来说，当堆有效范围为1时已经不需要再排，循环的条件也正是 i > 0，不是 i >= 0，省掉了数组长度为1时的一次多余操作。

整个排序过程看下来，核心动作只有三个：交换堆顶到末尾、缩小堆范围、对堆顶执行下沉。把这三个动作重复 n-1 次，数组就排好了。

4. 复杂度分析与实际表现：为什么堆排序“理论上很香，工程上却没那么常用”

4.1 很多人记错了，建堆的时间复杂度是 O(n) 而不是 O(nlogn)

不少人会把整段堆排序的复杂度笼统说成 O(nlogn)，然后默认建堆也是 O(nlogn)。这个说法不够精确。排序阶段的 n-1 轮调整确实每轮都是 O(logn)，所以排序阶段的复杂度是 O(nlogn)。但建堆过程单独算，复杂度其实是 O(n)。

要直观理解这一点，可以这么想：堆排序里调用 siftDown 的节点，所处层数越深，它下沉的距离就越短，而这样的节点数量越大。最底层上一层的节点大约有 n/2 个，每个最多下沉1次；再往上一层有 n/4 个节点，每个最多下沉2次；再往上 n/8 个节点，每个最多下沉3次。把代价和数量相乘再求和，是一个收敛的级数，结果不会超过 n 的常数倍。所以建堆复杂度是 O(n)，不是 O(nlogn)。

用数学表达会更清楚：设堆的高度为 h，从倒数第二层往上数，某一层的节点数约为 n/2^(k+1)，每个节点最多下沉 k+1 次，则该层总操作数约为 n * (k+1) / 2^(k+1)。把所有层的加总起来是一个常数级倍数乘以 n，因此整体是线性的。

这个结论在面试里经常被追问，答不出来或者直接说成 O(nlogn)，给面试官的印象就是深度不够。建堆复杂度是线性的，这件事也是堆能在大数据场景里高效运行的重要前提之一。

4.2 堆排序稳定吗？用一个 5a 和 5b 的例子说明不稳定

稳定性指的是排序后相同值的元素是否保持原来的相对顺序。堆排序是不稳定的，这一点必须记住。

为什么不稳定？根源在于堆调整过程中存在大量的“远距离交换”。一个节点可能从数组开头被一路换到很靠后的位置，也可能从末尾被换到前面，这种跳跃式的交换很容易把两个相等元素的先后顺序打乱。

举个例子，数组 [5a, 5b, 1]，其中5a和5b都等于5，5a在5b前面。建堆时，5a和5b都满足大顶堆的父节点值不小于孩子，所以堆顶是5a，数组保持 [5a, 5b, 1]。排序第一轮，堆顶5a和末尾1交换，数组变成 [1, 5b, 5a]。此时5a已经到了数组末尾，5b还在开头附近。接下来调整堆，5b会被调整到堆顶，最终排序结果是 [1, 5b, 5a]。你看，原本在前的5a跑到了后面，稳定性被破坏了。

如果你需要稳定排序，就不要选堆排序。归并排序的时间复杂度同样是 O(nlogn)，而且稳定，代价是需要 O(n) 的额外空间。快速排序也可以做到稳定，只是工程实现起来比较麻烦。堆排序的“不稳定”特性在面试中是一个高频追问点，回答时用这种简短的例子演示最直观。

4.3 堆排序、快排、归并的实际体验：为什么系统排序不用堆

如果单看时间复杂度，堆排序最好、最坏、平均都是 O(nlogn)，看起来非常稳。那为什么 C++ 的 sort 或者 Java 的 Arrays.sort 不用堆排序？原因有几个。

第一，堆排序对缓存的利用很差。数组中的元素访问虽然是连续的，但堆调整时父子节点之间的下标跳跃会带来较大跨度。比如 i 和它的孩子节点 2i+1、2i+2 之间，随着 i 的增大，步长变化是成倍增长的。越往堆底走，父子节点在数组中的距离可能越远，CPU 缓存命中率自然就低。快速排序即使最坏情况退化到 O(n²)，平均情况下对连续内存的顺序访问非常友好，实际运行速度往往比堆排序快不少。

第二，堆排序在调整过程中做过多的比较和交换。即使一个堆基本已经接近有序，堆顶下沉时仍然要一路比较到正确位置，很难提前终止。快排和归并则有很多局部有序的优化空间，比如对小区间切换插入排序、检测到已经有序就直接返回等。堆排序几乎没有这类“提前退场”的捷径。

第三，堆排序不稳定。系统级排序函数往往要同时满足稳定性、通用性和性能要求，虽然稳定性不是所有场景必须，但语言标准库通常会倾向于提供一个稳定的默认排序，或者像 C++ 那样同时提供 sort 和 stable_sort 两个选项。堆排序在这两者之间显得有些尴尬。

那堆排序真的没用吗？不是。它在嵌入式环境等内存受限场景里优势很明显，因为不需要额外空间。更重要的是，堆这种数据结构本身是优先队列的基石，排序只是它的一个应用分支。你在工作中遇到的 TopK 问题、定时器管理、Dijkstra 最短路径，底层都在用堆的思想，能写好堆的人才不会只把它当成一种排序算法来背。

5. 高频踩坑与排查实录：手写堆排序时最容易错在哪些地方

5.1 我见过最多的五个坑，每个都能让程序悄悄出错

结合我带过的人和自己踩过的坑，我把堆排序的高频问题整理成了一份速查表，方便你写代码时对照检查。

第一行的公式混淆问题在初学者身上出现频率最高。原因是大部分教材推导时使用从1开始的数组，但代码实现时语言默认从0开始，很多人复制代码时会忘记转换。我一开始也是这样栽的跟头。

第二行的无符号整数问题很隐蔽。看代码时觉得 for (int i = n/2-1; i >= 0; --i) 没什么问题，但如果函数里不够细心把 i 写成 size_t，那么当 i 变为0后再执行 --i，它不会变成 -1，而是变成一个巨大的正整数，循环条件 i >= 0 永远成立，程序直接死循环。这类 bug 调试起来很难发现，因为逻辑上根本没毛病。

5.2 一个稳定的验证方法：用三种数据测试你的堆排序

写完堆排序别急着提交或者投入使用，先用三组数据做快速验证。

第一组是随机乱序数组，比如 [4, 10, 3, 5, 1]，用来确认基本排序逻辑正确。第二组是已经有序的数组，比如 [1, 2, 3, 4, 5]，用来排查边界条件，因为有序数据在建堆和调整时会有大量重复比较，容易暴露循环终止条件不对的问题。第三组是含有大量重复值的数组，比如 [5, 5, 5, 1, 3, 3]，用来验证元素相等时程序不会死循环或产生奇怪的交换。

我还会加一个简单的断言式验证：排序后遍历数组，如果 a[i] > a[i+1]，直接报错。这个方法比肉眼检查快得多，也能在自动化测试里发挥价值。

另外，如果你需要调试堆排序的中间状态，可以在建堆后和每轮排序后输出数组，肉眼观察堆顶是否总是当前最大值、被交换到末尾的元素是否确实已经有序。这样的调试方式比单步跟更快。

6. 从堆排序延伸出去的“堆思维”：优先队列、TopK 与其他算法场景

6.1 遇到“找最大K个数”类问题，先用小顶堆试试

工作中真正让你手写整个堆排序的机会不多，但“从海量数据里找最大的K个数”这类问题很常见。它的标准解法就是维护一个大小为 K 的小顶堆。

具体思路是：先拿前 K 个数据建一个小顶堆，堆顶是当前 K 个数里最小的。然后从第 K+1 个数开始遍历，每来一个数就和堆顶比较，如果它比堆顶大，就把堆顶替换成这个新数，再做一次下沉调整。最终留在堆里的 K 个数就是全局最大的 K 个。

为什么要用小顶堆而不是大顶堆？因为小顶堆能保证堆顶是当前 K 个候选里的“门槛”，只有比门槛大的新元素才有资格进入候选集合。如果反过来用大顶堆，堆顶是最大值，那每次都要把最大值淘汰掉，这不符合我们要保留最大值的逻辑。这些问题本质上都是在考察你对堆顶和堆调整方向的敏感度。

6.2 不只是排序：堆在 Dijkstra、贪心算法中的角色

堆排序会让人产生一种错觉，觉得堆只是个排序工具。真正进入工程场景后会发现，只要涉及“动态取最值”，堆往往是第一选择。

比如 Dijkstra 最短路径算法中，每次都要从未访问节点中选出当前距离最小的节点进行松弛。如果每次都用扫描的方式找，复杂度是 O(n²)，图一大就跑不动了。用小顶堆维护候选节点的距离，每次取堆顶的代价是 O(logn)，整体复杂度能降到 O((n+m)logn)。

贪心算法里也有类似的用法。比如每次要取当前价值最高或代价最小的任务，如果数据集合不断变化，保持一个堆并实时调整，比每次重新排序高效得多。这也就是为什么很多讲贪心的文章会跟堆并列出现，它们解决问题的场景天然互补。

6.3 如果必须稳定又高效，应该怎么选型

回到排序本身，如果你在看堆排序代码时产生了“这个算法为什么在实际项目中用得少”的疑问，我的建议是：选排序算法时不要执着于某一种，要根据场景判断。

内存极其紧张、又必须原地排序、还不要求稳定，那堆排序是很合理的方案。要求稳定且内存充足，归并排序更合适。平均性能要求最高、实现复杂度和缓存友好度都要兼顾，那直接使用各语言标准库里的快排变种就好。工程上宁可采用经过大量优化的库函数，也不要轻易自己去实现一个基础排序算法，除非你明确知道自己在做什么。

我在实际开发里写过堆的地方，几乎都不是为了排序本身，而是为了维护一个动态变化的优先级队列。比如一个任务系统里，随时会有新任务插进来，老任务也会变更优先级，用堆来维护“下一个最该执行的任务”比每次全量排序省太多时间。这种“动态取极值”的思路，才是堆排序留给我最深的经验。

很多人学堆排序时把重心放在背代码上，我觉得不如多问自己几个为什么：为什么从 n/2-1 开始建堆？为什么升序用大顶堆？为什么交换后要重新下沉堆顶？把这几个问题想透，堆排序就不再是记忆负担，而是一种可以随时随地推导出来的技能。等到你熟练到能够闭着眼写出 siftDown 的迭代实现时，再回头看 TopK 和 Dijkstra 里的堆用法，会觉得它们的难度降了一大截。