C语言堆排序从原理到实现：复杂度、稳定性与工程实战

堆排序这东西，说实话，刚学C语言的时候我完全没当回事。当时满脑子都是冒泡排序、选择排序这些"老朋友"，觉得堆排序不就是个面试题吗。直到后来在项目里真正遇到一批必须保证最坏情况性能的排序需求，快排在最坏情况下退化到O(n²)让我差点线上翻车，才认认真真把堆排序从头到尾撸了一遍，顺手用C语言实现了一个能直接用的版本。

这篇就把堆排序从原理到C语言完整实现，再到实际开发里那些文档上不会写的坑，一次讲透。教程主要面向正在学数据结构的同学、考研刷题党，以及那些想在实际项目里用C语言做好性能兜底的嵌入式或者后台开发者。

1. 堆排序到底在做什么：先搞清楚堆是什么

网上很多文章一上来就甩代码，看完了还是不知道为什么要这么做。我们先退一步，把堆这个东西真正搞明白。

1.1 堆的本质：用数组画出的一棵完全二叉树

堆本质上就是一棵完全二叉树，但这棵树不是用指针串起来的，而是直接存在数组里。用数组存树，这件事本身就是一个非常巧妙的套路：对于数组下标为 i 的元素，它的左孩子下标永远是 2 * i + 1，右孩子下标永远是 2 * i + 2，父节点下标永远是 (i - 1) / 2（整数除法，向下取整）。这套映射关系不需要存任何额外指针，光靠下标计算就能在树和数组之间来回切换。

C语言里数组访问本身就快，指针满天飞反而容易出错，这种"隐式树"的存法是空间利用率和访问效率的平衡点。堆排序里的"堆"还额外加了一个约束：大顶堆保证每个父节点的值都不小于它的孩子节点。也就是说，堆顶元素永远是整棵树里的最大值。如果你维护的是小顶堆，堆顶就是最小值。排序一般用大顶堆，因为我们要把最大值"浮"到数组最后面。

这么设计的好处，类比一下：你手里有一副凌乱的扑克牌，堆排序做的不是逐张比较，而是先把整副牌整理成一个"金字塔"，塔尖是最大的牌。然后你每次只需要从塔尖拿一张，再把剩下的重新整理成金字塔。重复这个过程，整副牌就排好了。

1.2 为什么堆排序值得学：三个维度看价值

先说时间维度。堆排序最坏、最好、平均时间复杂度都是 O(n log n)，注意是"都是"。这意味着无论数据初始状态是顺序、逆序还是乱序，它都能保持稳定水准。相比之下，快速排序虽然平均也是 O(n log n)，但数据恰好排好序时如果选了固定基准点，会退化到 O(n²)。看到这里，你应该明白我开头说的那个场景，最坏性能兜底这个活，堆排序确实更扛得住。

再谈空间维度。整个堆排序算法只在原数组上进行，没有引入一个额外的辅助数组，空间复杂度是 O(1)。这一点在很多内存极其受限的嵌入式环境下很关键。

最后看算法设计的精巧度。堆排序本质上是一个选择排序的升级版。选择排序每次都要线性扫描找最大值，所以才慢；堆排序通过维护堆结构，把"找最大值"这一步从 O(n) 降到 O(log n)，整体性能自然上来了。

注意：堆排序是不稳定排序。什么叫不稳定？举个例子，数组里有多个相同值的元素，排序后它们的相对顺序可能发生变化。如果你的业务场景要求排序后相同关键字元素保持原有先后顺序，堆排序直接不合格。

2. 核心操作拆解：heapify 是堆排序的心脏

堆排序总代码量不大，但核心就一个函数——heapify。这个函数干的事只有一个：假设某个节点的左右子树都已经满足大顶堆条件，但当前节点可能不满足，那么把它一路往下调整，直到以它为根的整棵子树重新满足堆条件。

2.1 max-heapify 的工作原理

判断过程其实很简单：

1. 当前节点下标为 i，先把 largest 设为 i。
2. 计算左孩子下标 l = 2 * i + 1，右孩子下标 r = 2 * i + 2。
3. 如果 l < n 且 arr[l] > arr[largest]，更新 largest = l。
4. 如果 r < n 且 arr[r] > arr[largest]，更新 largest = r。
5. 如果 largest 不是 i，说明当前节点不是最大值，就交换 arr[i] 和 arr[largest]，然后递归对 largest 位置继续做 heapify。

这里有个细节你一定要留意：为什么跟左右孩子比较，左右孩子直接不比较？因为左右子树本身已经是大顶堆，它们的根节点是各自子树里的最大值。三个值里取一个最大的，只需要当前节点分别跟两个孩子比较就够了，不需要额外比较两个孩子之间的关系。

每次交换之后，等于把一个大一点的数挪到了上面，原来在父节点位置的较小值被打到了下面，这个较小值跑到新子树里可能仍然不满足堆条件，所以要继续递归下沉。这个过程最坏情况下要走完从根到叶子的整条路径，所以时间复杂度是 O(log n)。

2.2 从下往上建堆：为什么不是从上往下

如果给你一个乱序数组，想要建成一个大顶堆，该怎么建？

一种直觉是从根开始，从上往下把每个节点都做一次 heapify。试一下就不对劲了：如果根节点的值很小，heapify 可以把它往下压，但根节点原本左右子树里的较大值还在原位，它们可能都不满足各自的子堆条件。因为你是从上往下建的，下面还没处理过，heapify 的前提根本不成立。

正确姿势是从最后一个非叶子节点开始，从下往上对每个节点执行 heapify。最后一个非叶子节点的下标怎么找？用最后一个节点的父节点下标就能得到：n / 2 - 1（n 为数组长度）。

为什么从下往上就对了？因为当你处理到某个非叶子节点时，它的左右子树已经在上一轮被处理成合法的大顶堆了。heapify 的假设条件成立，递归步骤就畅通无阻。

build_max_heap 的 C 语言写法大概是：

c复制void build_max_heap(int arr[], int n) {
    for (int i = n / 2 - 1; i >= 0; i--) {
        heapify(arr, n, i);
    }
}

这个循环从中间位置往前走到 0，复杂度看起来是 O(n/2 * log n)，但你可以记住一个结论：自底向上建堆的总复杂度是 O(n)。原因很简单：下层节点的高度很小，大多数节点只需要做常数次比较，真正从根一路下沉到叶子的只有少数几个节点。摊还下来就是 O(n)。

这个结论我在面试里被人问过好几次，很多人一听 O(n) 都觉得不可思议。你直接用数学归纳法推一次就明白了：处理高度为 h 的节点，最多做 h 次交换；整棵完全二叉树高度为 h 的节点个数大约有 n/2^(h+1)，总操作量是一个收敛的级数，上限就是 O(n)。

3. 完整 C 语言实现：每一行代码都讲清楚

前面原理吃透了，代码写起来就很顺。这里给一个可以直接编译运行的完整版本。我是按 C11 标准写的，编译器用 GCC 实测没问题，Linux 和 Windows 下都能跑。

3.1 数据结构和辅助函数

堆排序我们用裸数组操作，没必要包结构体。但要养成好习惯，加一个 swap 函数，避免在排序主循环里重复写交换逻辑。

c复制#include <stdio.h>

// 交换两个整数的值
void swap(int *a, int *b) {
    int tmp = *a;
    *a = *b;
    *b = tmp;
}

// 自适应最大值堆调整
void heapify(int arr[], int n, int i) {
    int largest = i;
    int left = 2 * i + 1;
    int right = 2 * i + 2;

    // 如果左孩子存在且比当前节点大，更新largest
    if (left < n && arr[left] > arr[largest]) {
        largest = left;
    }
    // 如果右孩子存在且比当前最大值还大，更新largest
    if (right < n && arr[right] > arr[largest]) {
        largest = right;
    }

    // 如果最大值不是当前节点，交换并继续调整
    if (largest != i) {
        swap(&arr[i], &arr[largest]);
        heapify(arr, n, largest);
    }
}

这里的 n 是当前堆的有效长度。排序过程中堆会越来越小，所以 heapify 的 n 是变化的主要参数。我见过有人把 n 当成全局数组长度，结果排序到后面就乱了，这就是没意识到堆的有效范围在收缩。

3.2 排序主流程逐步解析

排序主流程就三个阶段：

1. 建堆。
2. 把堆顶元素（最大值）和当前堆的最后一个元素交换。这个元素就到了它的正确位置，留在那里不用再动。
3. 堆的有效长度减一，对堆顶重新执行 heapify，恢复大顶堆。

循环执行第 2 步和第 3 步，直到堆里只剩一个元素，排序完成。

c复制void heap_sort(int arr[], int n) {
    // 1. 建大顶堆
    for (int i = n / 2 - 1; i >= 0; i--) {
        heapify(arr, n, i);
    }

    // 2. 从最后一个元素开始逐个与堆顶交换
    for (int i = n - 1; i > 0; i--) {
        // 把当前最大值放到数组尾部
        swap(&arr[0], &arr[i]);
        // 剩下的元素重新调整堆
        heapify(arr, i, 0);
    }
}

这里最关键的一行是 heapify(arr, i, 0)，传入的 n 变成了 i。因为交换完之后，数组末尾的 i 位置已经装着一个排好序的最大值，它不应该再参与堆调整。如果不把有效长度减一，好不容易放到后面的最大值又会被 heapify 翻到堆顶，整个排序就废了。

我自己第一次实现的时候，就是在这里犯迷糊。盯着屏幕看了半天，最后加了一行 printf 打印每次调整后的数组，才发现是边界没处理好。

3.3 测试、打印与验证

为了看到排序过程和结果，写一个 printf 辅助函数，顺便在 main 函数里跑几组测试数据。

c复制void print_array(int arr[], int n) {
    for (int i = 0; i < n; i++) {
        printf("%d ", arr[i]);
    }
    printf("\n");
}

int main(void) {
    int arr1[] = {5, 2, 8, 1, 9, 3, 7, 4, 6, 0};
    int n1 = sizeof(arr1) / sizeof(arr1[0]);

    printf("原始数组: ");
    print_array(arr1, n1);

    heap_sort(arr1, n1);

    printf("排序后:   ");
    print_array(arr1, n1);

    // 边界情况：只有一个元素
    int arr2[] = {42};
    int n2 = sizeof(arr2) / sizeof(arr2[0]);
    heap_sort(arr2, n2);
    printf("单元素数组: ");
    print_array(arr2, n2);

    // 边界情况：已经有序
    int arr3[] = {1, 2, 3, 4, 5};
    int n3 = sizeof(arr3) / sizeof(arr3[0]);
    heap_sort(arr3, n3);
    printf("已排序数组: ");
    print_array(arr3, n3);

    // 边界情况：全部相同
    int arr4[] = {7, 7, 7, 7, 7};
    int n4 = sizeof(arr4) / sizeof(arr4[0]);
    heap_sort(arr4, n4);
    printf("全部相同: ");
    print_array(arr4, n4);

    return 0;
}

用 sizeof(arr) / sizeof(arr[0]) 来计算数组长度是 C 语言里的常规操作，但有一个前提：arr 必须是数组名，而不是传入函数后的指针。如果你在 heap_sort 函数体里用同样的写法，得到的一定是指针大小除以 int 大小，结果完全错误。这也是初学者经常踩的坑，排序结果乱套的时候先检查这里。

一组典型输出是：

code复制原始数组: 5 2 8 1 9 3 7 4 6 0
排序后:   0 1 2 3 4 5 6 7 8 9
单元素数组: 42
已排序数组: 1 2 3 4 5
全部相同: 7 7 7 7 7

四种边界情况都测了，程序没有野指针也没有越界，说明核心流程基本是健壮的。

4. 常见问题与调试实录

写堆排序的代码，最难的不是把思路写出来，而是出错了不知道怎么定位。这里把我实际踩过的坑和排查方式整理成一张速查表，你可以直接照着查。

4.1 边界条件导致的越界与错误

4.1.1 孩子下标越界是最大隐患

堆排序的代码大概率不会段错误，但出错反而是隐藏的。最典型的场景就是 child 下标越界，比如 i = n/2 的节点，它没有左孩子，但代码里若没有加 left < n 判断，就会访问 arr[n] 甚至越界到更远的内存。

我排查越界问题的经验是先检查两个地方：一是所有访问数组的地方有没有下标小于 n 的判断；二是循环退出条件是不是用了 > 而不是 >=。堆排序里这个错误很隐蔽，因为单排一组随机数据可能刚好不触发，但一旦数据规模变大或者构造出特殊的完全二叉树形状，问题立刻暴露。

调试这类问题，我自己比较习惯用 AddressSanitizer（简称 ASan），这是编译器自带的越界检查工具。编译时加一个参数就行：

bash复制gcc -fsanitize=address -g heap_sort.c -o heap_sort

加上这个参数后，任何越界访问都会在运行时报出具体行号，根本不用自己盲猜。很多 Linux 下的 C 程序员还没养成随手开 ASan 的习惯，其实这个工具可以说是排查内存问题的第一神器。

4.1.2 排序结果里面的"漏网之鱼"

有同学跑完堆排序，发现数组基本有序，但中间有零星几个数字不对。这种情况十有八九是堆的"有效长度"没控制好。回想排序主循环：

c复制for (int i = n - 1; i > 0; i--) {
    swap(&arr[0], &arr[i]);
    heapify(arr, i, 0);  // 这里必须传 i，而不是 n
}

为什么必须传 i？因为 arr[i] 已经放到正确位置了，本轮之后不该再参与堆操作。如果你传的是 n，堆顶下沉时会把还没处理完的堆元素和已经排好的后缀混在一起，结果就是大值会跑到后缀里搅乱顺序。

这种问题肉眼其实很难发现，因为堆的形态被你弄乱了，输出结果乍一看"大致有序"，但每次都有几个越界。排查时把 heapify 函数里的 left < n 和 right < n 改成 < i，保持跟堆有效长度一致，问题就消失了。

4.2 heapify 迭代实现：如何避免递归堆积

递归实现非常直观，但遇到特别大的数组时，递归深度最多也就是 O(log n)，理论上没有栈溢出风险。不过 C 语言里递归函数调用有函数调用开销，性能敏感的项目里我更推荐迭代版本。

c复制void heapify_iter(int arr[], int n, int i) {
    while (1) {
        int largest = i;
        int left = 2 * i + 1;
        int right = 2 * i + 2;

        if (left < n && arr[left] > arr[largest]) {
            largest = left;
        }
        if (right < n && arr[right] > arr[largest]) {
            largest = right;
        }

        if (largest != i) {
            swap(&arr[i], &arr[largest]);
            i = largest;
        } else {
            break;
        }
    }
}

迭代版本里，每次交换完，只需要把 i 更新为 largest，然后继续下一轮循环。逻辑跟递归完全等价，但省掉了函数栈的压弹开销，代码量也没多多少。我自己实际测过，一千万个随机数，两者时间差距在几个百分点左右，经典老编译器下递归版本稍慢一些，当用 -O2 编译后几乎持平。

4.3 稳定性问题与使用场景限制

堆排序的不稳定性是它的固有属性，不是 BUG。具体来说，构建大顶堆的过程中，两个值相等的元素可能会交换相对位置。后面排序时，堆顶元素被甩到数组末尾，这个交换同样会打乱相等元素原有的顺序。

我的实际建议是：如果业务数据里有多个关键字，并且你希望保持相同主关键字记录的原始顺序，不要用堆排序，改去用归并排序或者插入排序的变种。如果只是对记录的某个数值字段排序，并且不关心相同值的先后顺序，堆排序就是一个很好的选择。

我这里就处理过一个日志系统，对一千万条日志按时间戳排序，相同时间戳的不同日志谁在前谁在后完全无所谓。这种情况下用堆排序非常合适，空间省，时间也稳定，完全绕开快排最坏情况退化的风险。

4.4 堆排序调试日志的埋点技巧

当你觉得算法逻辑没问题但结果不对的时候，别急着盯着代码空想。我强烈建议在关键流转处埋几行调试日志。

比如建堆完成后先打印一次数组，看看堆顶是不是最大值。如果堆顶不是最大值，说明建堆肯定有问题。然后每次交换和 heapify 之后再打印一遍数组，用眼睛观察最大值是不是逐步往后"沉淀"。这种可视化过程很快就能定位到是哪一步错了，是建堆错了还是交换后没有恢复堆，一目了然。

记住：打印日志是找 bug 的加速器。写完代码后先跑小规模数据（比如 6 到 8 个元素）手动模拟，确认没问题了再上大规模测试。千万别一上来就拿十万个数据跑，问题会被埋没在大数据量里。

4.5 空数组和异常输入的处理

这个很多人会忽略。真实业务环境里，你不可能保证调用者永远传给你一个合法非空数组。我写的 heap_sort 函数会先判断：

c复制if (arr == NULL || n <= 1) {
    return;
}

n <= 1 的时候根本不用排序，直接返回。arr == NULL 时也要防一手，不然一运行就段错误，线上事故就是这么来的。别嫌这个判断多余，在嵌入式项目里，一个空指针多走了一层函数，会直接让单片机复位。

5. 复杂度分析与工程选型建议

堆排序在复杂度层面有一个很不错的特性：无论数据长成什么样，算法耗时都保持在一个可控范围内。这个特点在实时系统或对延迟有硬性要求的场景里特别值钱。

5.1 时间复杂度的直觉理解

很多人把堆排序的时间复杂度笼统记成 O(n log n)，但具体到各个阶段，理解起来更透彻：

• 建堆阶段：O(n)。前面讲过，因为大部分节点只经历很少的下沉。
• 每次取走堆顶并重新 heapify：O(log n)。
• 总共要取 n-1 次堆顶：O(n log n)。

所以总复杂度是 O(n + n log n)，也就是 O(n log n)。空间复杂度 O(1)，因为所有操作都在原数组上进行。如果你跟面试官聊到这里，再补一句"建堆其实是 O(n) 而不是 O(n log n)"，会很明显地让他觉得你是真的懂这个算法，而不是背了个结论。

5.2 堆排序 vs 快排 vs 归并排序

这是工程选型时最核心的一张对比表，我直接用实际经验整理成表格，你一眼就能看清差异：

快速排序实际工程里通常最快，依赖 CPU 缓存局部性，数据在内存里连续跳着访问也没问题。但它的最坏情况退化是个心腹大患。虽然可以通过随机选基准点缓解，在某些完全不能用随机数的环境下依然头疼。

归并排序稳定，但需要 O(n) 额外空间。像链表排序、外部排序这种不能整套搬进内存的场景，归并排序几乎是唯一选择。

堆排序的优势就是数据和空间都省心，劣势在于它在实际运行时对内存的访问是跳跃式的，缓存命中率不如快排，所以同样的 O(n log n)，常数项稍大。排序一亿个整数，堆排序比快排通常慢 20%-30%，这个代价换来的最坏性能兜底，在很多场景里是值得的。

5.3 优先级队列：堆排序的"亲兄弟"

其实堆排序更大的价值不是排序本身，而是堆这个数据结构在"优先级队列"里的应用。优先级队列的核心能力是随时取出最大值或最小值，并且插入和提取都是 O(log n)。

C 标准库里没有内置优先级队列，项目里只要你写出了正确的 heapify，就能顺手封装出一个可用的优先级队列。比如任务调度器，系统按任务优先级依次执行，同时又可能要插入新任务，这种场景就是堆的天花板。

我在嵌入式定时器模块里就用小顶堆管理一堆定时事件。每次要取出最近要触发的事件，只读取堆顶就行，复杂度 O(1)；插入新事件时把新节点加到堆尾，再向上冒泡维护小顶堆，复杂度 O(log n)。这个方案比每次线性扫描一个有序链表要高效得多，代码量还少。

5.4 如何用生成器和随机数据做基准测试

写完排序算法，不测一下性能就说完成了，是初学者最容易犯的毛病。写一个简单的基准测试程序，用随机数生成器填充大数组，再用 clock 函数计时，能直观地看到算法在各种数据量下的表现。

c复制#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main(void) {
    srand((unsigned)time(NULL));
    int n = 1000000;
    int *arr = (int *)malloc(sizeof(int) * n);
    if (arr == NULL) return 1;

    for (int i = 0; i < n; i++) {
        arr[i] = rand() % 1000000;
    }

    clock_t start = clock();
    heap_sort(arr, n);
    clock_t end = clock();

    printf("排序 %d 个元素耗时: %.3f 秒\n",
           n, (double)(end - start) / CLOCKS_PER_SEC);

    free(arr);
    return 0;
}

同样的数据规模，再换快排基准测试程序对比一下，能得出很多有价值的结论。注意 clock 函数统计的是 CPU 时间而不是墙钟时间，在多线程环境下会有偏差。更严格的做法是用 clock_gettime 加 CLOCK_MONOTONIC，但对初学者来说 clock 完全够用了。

5.5 什么情况下我不推荐你写堆排序

虽然堆排序听起来挺完美，但工程上手你还是要克制。举个例子，如果排序的数据量很小（比如几十个元素），插入排序比堆排序快得多。因为插入排序常数项极小，十几二十个元素几乎就是最优解。很多 C 标准库的 qsort 内部在区间长度小于某个阈值时，都会切到插入排序，连底层都在用这个策略。

另外，如果数据本身基本有序，插入排序或者冒泡排序有接近 O(n) 的真实表现，堆排序老老实实走 O(n log n)，反而吃亏。判定标准很简单：数据量小选插入排序，数据量大且担心最坏情况选堆排序，数据量大且内存充足且要求稳定选归并排序，数据量大且缓存友好性要求高选快排。

6. 手把手带你过一遍完整推演

光说不练假把式。这里用一个 6 个元素的数组来做手算推演，跟着走一遍，堆排序的每一步都会变得非常清晰。

原始数组：[4, 10, 3, 5, 1, 9]，长度 n = 6。

第一步，建堆。最后一个非叶子节点下标是 n / 2 - 1 = 2。节点 arr[2] = 3，左右孩子分别是 arr[5] = 9（右孩子），左孩子下标 5 已经超出 n = 6 范围吗？并没有，left = 5，但它的左孩子index是 11，明显越界，所以只比较它和右孩子。9 比 3 大，交换它们。此刻数组变成 [4, 10, 9, 5, 1, 3]。

接着 i = 1，节点 arr[1] = 10，左孩子 arr[3] = 5，右孩子 arr[4] = 1。10 已经是最大的，不用动。

再 i = 0，节点 arr[0] = 4，左孩子 arr[1] = 10，右孩子 arr[2] = 9。最大值是 10，在 largest = 1，交换 arr[0] 和 arr[1]，数组变成 [10, 4, 9, 5, 1, 3]。然后递归调整 i = 1 位置：节点 4，左孩子 5，右孩子 1，最大是 5，交换 arr[1] 和 arr[3]，数组变成 [10, 5, 9, 4, 1, 3]。堆顶 10 是最大值，建堆完成。

排序阶段：

• 交换 arr[0] 和 arr[5]，得到 [3, 5, 9, 4, 1, 10]，堆有效长度变为 5。对堆顶 3 做 heapify，发现最大值是 9（在下标 2），交换后等得到 [9, 5, 3, 4, 1, 10]。
• 交换 arr[0] 和 arr[4]，得到 [1, 5, 3, 4, 9, 10]，堆有效长度变为 4。堆顶 1 下沉，5 和 4 都比它大，最大的是下标 1 的 5，交换后变成 [5, 1, 3, 4, 9, 10]，1 又下沉到下标 3 的位置，跟 4 交换，数组变成 [5, 4, 3, 1, 9, 10]。
• 交换 arr[0] 和 arr[3]，得到 [1, 4, 3, 5, 9, 10]。堆有效长度变为 3。堆顶 1 下沉，4 和 3 比它大，换成 [4, 1, 3, 5, 9, 10]。
• 交换 arr[0] 和 arr[2]，得到 [3, 1, 4, 5, 9, 10]。堆有效长度变为 2。堆顶 3 比左孩子 1 大，不用换。
• 交换 arr[0] 和 arr[1]，得到 [1, 3, 4, 5, 9, 10]。

排序完成。整个过程中，最大值一步一步从堆顶被"搬到"数组尾部，小值逐渐被还原到堆中，这是理解堆排序最直观的动态画面。

7. C 语言实现堆排序的扩展思考

到这里，堆排序的核心你已经掌握了。但作为拓展开的几件事，我也按实用优先级给你说一下。

7.1 用哨兵简化代码还是按标准写

有些人喜欢把数组下标从 1 开始建模，这样左孩子就是 2*i，右孩子是 2*i+1，父节点是 i/2，比从 0 开始更接近教科书上的伪代码。代价是数组第一个元素（下标 0）就被浪费了。

C 语言里数组默认从 0 开始，除非你设计一个"arr[0] 只作哨兵"的结构，否则保持从 0 开始的写法更符合内存布局习惯，函数接口也更能无缝对接其他代码。我几次试用过从 1 开始的下标实现，最后都改回去了，因为一旦传入外部数组，那个浪费的位置会让调用方一头雾水。

7.2 如何把 heap_sort 封装成可复用模块

如果你准备在公司内部项目里用好堆排序，我建议把它放在头文件和源文件分离的模块里。头文件 heap_sort.h 里只暴露一个函数声明：

c复制#ifndef HEAP_SORT_H
#define HEAP_SORT_H

void heap_sort(int arr[], int n);

#endif

源文件里把 swap 和 heapify 都定义为 static，让它们只在当前编译单元可见。这样对外接口干净，内部细节不会污染别的模块，也能避免多个文件之间的符号冲突。

7.3 堆排序与其他排序结合的组合策略

工程实战里，单一排序算法经常不够用。在很多现代 C 标准库的排序实现里，快排配合插入排序，快排区间小时切换插入排序。堆排序也可以这样干：比如先快速排序，但当快排递归的分区大小小于一个阈值（比如 16）时，改用堆排序防止最坏情况。这种"混合算法"策略能同时利用快排的缓存友好性和堆排序的最坏情况兜底能力。

我自己实现过一个混合排序，整体性能比单独快排略低一点，但最坏运行时间有了保证。真实系统里，在超时敏感的模块中，这种牺牲一点平均性能换最坏性能的做法，常常是稳定性高于一切的刚需。

7.4 堆排序的常见变形与延伸

大顶堆能排序升序，小顶堆能排序降序，这是最基础的变形。更深层的应用是 Top K 问题：维护一个大小为 K 的小顶堆，遍历数据流时只保留当前最大的 K 个，遍历结束后堆顶元素就是第 K 大的数。这个技巧在海量日志、排行榜、流式计算里用得非常多。

还有一种叫"堆式排序"的场景，是给一批异构任务做优先级排序，任务重量差异很大。普通数组排序要复制大量数据，堆排序只需要交换索引数组，再用索引去访问真实数据。内存访问跳来跳去，但任务本身不会被复制，省下来的开销非常可观。

这里我特别想提一下在嵌入式设备上用堆排序的好处：设备的 RAM 通常只有几 KB 到几百 KB，堆排序排一个千级规模的数组只占用了原数组那块内存，不额外要缓冲区。我做过一个温控器项目，数据采集后要按温度值排序，当时芯片内存紧张到连快排递归栈都心疼，换成堆排序之后，任务调度稳定多了。

7.5 我要不要用 qsort 替代自己写的堆排序

C 标准库自带 qsort，但它不能保证最坏时间复杂度，实际表现还取决于比较函数和平台实现。如果你只需要一个"差不多快"的排序，直接用 qsort 就好；如果你明确要求最坏情况可控、空间占用为零，那自己实现堆排序就很合理。

需要注意：qsort 的比较函数接受 void * 指针，写起来稍微繁琐一点，但性能其实不错。我在项目里给结构体数组排序，还是在比较函数里做字段比较，并不会因为用了手写堆排序就放弃 qsort，二者各管各的应用场景。

8. 我在实际项目中使用堆排序后的一些心里话

写这篇文章之前，我把自己以前的排序代码拿出来重看了一遍，发现当年很多注释写得像天书，逻辑也绕来绕去。这次重新整理堆排序的时候，自己手写代码、手写测试、做基准测试，重新踩了一遍当年踩过的坑。最大的体会是：堆排序并不难，但它的每一行代码背后都有道理，理解了那些"为什么"，你才能真正驾驭它，而不是背代码。

如果你正准备面试，我建议的练习路径是：先手写堆排序的代码并在白板上解释每步的作用，再写一个堆排序的迭代版，最后用堆排序解决一道 Top K 的算法题。这三个能力点覆盖了大部分面试官对堆的考查范围。

如果你正打算把它用到真实项目里，记得先从边界条件开始测，尤其是空数组、单元素、全相同、已经完全有序这几种特殊输入。排序算法的坑往往不是在正常数据上，而是在临界输入上。

最后再分享一个很多老手才知道的小技巧：当你需要给数组排序，但是又希望保留原数组顺序时，别再写一堆复制逻辑了，直接创建一个下标数组，对下标数组做堆排序，比较时用原数组的值做依据。这样你既享受了堆排序的性能，又保住了原始数据不会被破坏，代价只是额外的一个 int 数组。在我处理的日志排序场景里，这个技巧帮我节省了大量内存拷贝的时间。

堆排序的完整代码、调试日志、基准测试方法在文章里都给你了，照着敲一遍、跑一遍、改一遍，比看十篇文章都有用。