从零实现链式队列：C语言详解先进先出数据结构与边界处理

数据结构学到栈这种“后进先出”之后，很多人会下意识觉得队列就是“反过来的栈”——这个理解没错，但很容易低估它。我在自己的学习笔记里写过一句话：队列不是一个辅助结构，而是一整套系统设计的底层逻辑。它出现在操作系统进程调度、打印机缓冲、网络数据包排队、线程池任务分发，甚至前端动画执行顺序里。而链式队列，正是理解这些真实场景最好的切口。

为什么要强调“链式队列”，而不是直接上手循环队列？因为链式队列的动态内存管理方式，最能还原队列数据结构最本质的动作——进入队列、离开队列，以及处理这两个动作之间各种临界状态的边界问题。这篇文章的目标很直接：从零构建一个链式队列，把设计思路、C语言实现、易错点、选型判断全讲明白。初学数据结构的同学可以当课堂笔记，考研复习的人可以拿来当作核心考点清单，已经在写工程代码的读者，也能从中找到和自己项目里消息队列、任务队列对应的那块基石。

1. 为什么是“先进先出”：队列这种结构要从哪里开始想

1.1 队列与栈的区别不仅仅是顺序

很多人学队列时，把队列理解为“栈反过来”，但真到做题和面试时，区分两种结构的关键不是顺序本身，而是“到底要保留什么状态”。

栈对应的是“最近优先”的诉求。浏览器后退、函数调用返回、表达式求值，都是最近的请求最先被处理，所以栈用后进先出最合适。队列对应的则是“公平优先”的诉求。任务到达后按照到达顺序被处理，谁先来谁先走，谁也不准插队。可以说，栈强调“恢复现场”，队列强调“维持顺序”，这种语义差异决定了它们在系统中的角色完全不同。

我第一次认真感受到这种差异，是看到操作系统里的进程调度。算法设计课上写的简单队列只是把几个整数插入删除，而操作系统却用队列管理成千上万个进程：新进程进入就绪队列，CPU 空闲时从队头取一个进程运行。这如果不用先进先出，那进程执行顺序就会乱套。队列是这个场景里最简单、最符合直觉的选择。

1.2 一个合格的队列实现必须支持哪些动作

从数据结构本身的定义来看，队列是“只允许在一端插入、另一端删除”的线性表。这种约束看起来单调，但也意味着队列的操作集合非常固定：插入只能在队尾，删除只能在队头，访问队头元素但不删除，判断队列是否为空。

为什么会产生“插入队尾、删除队头”这个方向，而不是反过来？因为只有这样才能保证先进先出。如果把插入和删除都放在同一端，得到的就是栈而不是队列。所以源码里最核心的函数其实就两三个：入队（enqueue）、出队（dequeue）、取队头元素（peek/front）。

在实现队列时，面临两种基本策略：用数组（顺序存储）还是用链表（链式存储）。数组实现的顺序队列有一个很尴尬的问题——出队操作会让前面的空闲位置闲置，要解决只能搬移数据，效率不高。链式队列因为天然是节点动态链接的，出队时直接让队头节点脱离，不会有数组那种空间浪费和搬移问题。这也是为什么链式队列是学习队列时绕不开的第一个完整实现。

2. 链式队列设计的关键取舍：链表、头结点和那个永不缺席的尾指针

2.1 为什么不能让“单链表的头指针”独自扛下所有

如果把队列直接建立在单链表上，最常见的思路是：队头放在链表头部，队尾放在链表尾部。出队操作直接删除头节点，时间复杂度 O(1)。但入队操作要在链表尾部插入，如果只保存头指针，每次都要从头节点遍历到链表末尾，时间复杂度 O(n)。

这个复杂度在最开始写代码时感觉不到差距，因为测试数据只有几个节点。但放到真实场景里，比如每秒有上万个请求进入任务队列，每次入队都遍历一次链表，系统性能会迅速崩塌。所以需要做的第一件事就是：在结构体里为队列单独保存一个尾指针（rear）。有了尾指针，入队时可以直接在尾指针指向的节点后面接新节点，时间复杂度变成 O(1)。

这里有个很容易犯迷糊的点：为什么出队不能在队尾进行，让尾指针同时承担出队和入队的任务？因为单向链表删除尾节点时，需要找到尾节点的前一个节点，仍然要遍历链表。要让删除尾结点也达到 O(1)，就得用双向链表，那需要付出的额外内存和维护成本就更高了。队列的根本需求是“先进先出”，与其两头都做复杂操作，不如一头进一头出，各司其职，整个设计最简单高效。

2.2 带头结点还是不带头结点：边界问题才是决策点

链式队列在结构上有一个绕不开的讨论：要不要加头结点（哨兵节点）。

不带头结点的实现是这样的：队列为空时 front 和 rear 都指向 NULL。第一次入队时，需要让 front 和 rear 同时指向新节点；之后再入队，只改变 rear 的 next 和 rear 本身。这导致入队函数里必须写一个 if 判断“当前是不是第一次插入”，代码看起来不复杂，但每次入队都要做分支判断，而且出队删到空时也需要把两个指针同时清空。

带头结点的实现则完全不同：初始时 front 和 rear 都指向一个不存储真实数据的哨兵节点。队列为空的判断条件是 front == rear。入队时无需判断当前是否有数据，直接在 rear 后面插入即可；出队时也无需担心“删掉最后一个元素后怎么重置指针”这种极端情况，只需要做一次额外的指针维护（这个细节后面会专门讲）。

我个人非常推荐初学者用带头结点的方式实现链式队列。它牺牲了一个节点的存储空间和一个空的初始化，换来的是所有边界逻辑的统一：空队列有统一表示，插入删除不需要写大量分支判断，代码的健壮性明显提高。在严蔚敏老师的《数据结构（C语言版）》中，链式队列也采用类似带队的思路来定义结构，考试复习时尤其要注意你所用的教材采用哪种定义方式，避免代码和书本约定不一致。

3. 从结构体到完整代码：我用C语言实现的链式队列

3.1 类型定义：别小看结构体的粒度

整个类型定义分两个部分：队列节点和队列本身。

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

typedef int ElemType;   // 先以 int 测试，实际业务中替换成目标类型

typedef struct QNode {
    ElemType data;
    struct QNode *next;
} QNode;

typedef struct {
    QNode *front;
    QNode *rear;
} LinkQueue;

不要在一开始就把 front 和 rear 直接定义成 QNode 指针，而是单独包装成一个 LinkQueue 结构体。原因有两层：一是函数传参更清晰，可以用一个 LinkQueue 指针代表“整个队列”，而不是去操作两级指针；二是后续如果要扩展队列属性（长度计数、加锁信息），只需要在 LinkQueue 中添加字段，不会破坏已有节点逻辑。

3.2 初始化和判空：定义一个“看起来有内容，其实为空”的队列

使用带头结点方案时，初始化函数要让 front 和 rear 共同指向一个刚分配的头结点。

c复制void initQueue(LinkQueue *Q) {
    Q->front = (QNode *)malloc(sizeof(QNode));
    if (Q->front == NULL) {
        perror("malloc failed");
        exit(1);
    }
    Q->front->next = NULL;
    Q->rear = Q->front;
}

bool isEmpty(LinkQueue *Q) {
    return Q->front == Q->rear;
}

这里的关键点是：front 指向的其实是头结点，front->next 才指向第一个有效数据节点。初始化后队列中没有任何实际数据，front 和 rear 都指向头结点，所以判空条件就是两者相等。理解这个结构，后面遍历和出队都顺畅了。

3.3 入队操作：先接链条，还是先移动尾指针？

入队的逻辑很直观：创建新节点，把数据放进去，然后让当前尾节点的 next 指向新节点，最后把尾指针移动到新节点上。代码可以这样写：

c复制void enQueue(LinkQueue *Q, ElemType e) {
    QNode *node = (QNode *)malloc(sizeof(QNode));
    if (node == NULL) {
        perror("malloc failed");
        exit(1);
    }
    node->data = e;
    node->next = NULL;

    Q->rear->next = node;
    Q->rear = node;
}

写这段代码时要注意的是先后顺序。必须先让原来的队尾节点 next 指向新节点，再移动 rear 指针。如果先移动 rear 再挂接新节点，会让原来队尾节点和新节点失去联系，队列链条就断掉了。这里还有一个细节值得注意：新节点的 next 一定要置为 NULL。如果不置空，节点内容来自 malloc 的未定义内存，后续遍历和销毁队列时会出现很多令人头疼的野指针问题。

3.4 出队操作：核心代码只有几行，但思想要很清晰

出队时先判断队列是否为空，空队列调用出队是非法操作，这个在设计上层 API 时要体现为返回值或异常。

出队的对象是第一个有效数据节点，也就是 Q->front->next 指向的节点。先取出它的数据，然后让 front 的 next 跳过这个节点，直接指向下一个节点，最后释放被删除节点。

c复制bool deQueue(LinkQueue *Q, ElemType *e) {
    if (isEmpty(Q)) {
        return false;
    }
    QNode *del = Q->front->next;
    *e = del->data;
    Q->front->next = del->next;

    if (del == Q->rear) {
        Q->rear = Q->front;
    }

    free(del);
    return true;
}

这里那一句 if (del == Q->rear) Q->rear = Q->front; 绝对不是可有可无的。它处理的是“队列只有一个有效节点”的情况。删除这唯一的节点后，如果不把 rear 拉回到头结点，rear 就会指向一块已经释放的内存。下一次入队直接访问 Q->rear->next 就会往已释放空间写入，程序表现就是“时好时坏、偶发崩溃”。这个坑，后面我会专门拿出一个小节来讲。

3.5 取队头、清空与销毁：补齐队列的完整生命周期

入队和出队是队列的核心操作，但一个工程可用的队列还需要取队头数据和销毁清理。

c复制bool getHead(LinkQueue *Q, ElemType *e) {
    if (isEmpty(Q)) {
        return false;
    }
    *e = Q->front->next->data;
    return true;
}

void clearQueue(LinkQueue *Q) {
    QNode *cur = Q->front->next;
    while (cur != NULL) {
        QNode *next = cur->next;
        free(cur);
        cur = next;
    }
    Q->front->next = NULL;
    Q->rear = Q->front;
}

void destroyQueue(LinkQueue *Q) {
    clearQueue(Q);
    free(Q->front);
    Q->front = NULL;
    Q->rear = NULL;
}

clearQueue 严格说是“把队列清空，但队列本身还能再用”。destroyQueue 则是把所有申请的内存包括头结点一并释放，之后队列就不存在了。两者语义不同，实际代码里还是分开写比较好。我见过不少同学只写 destroyQueue 不写 clearQueue，临时想清空队列时只能销毁重建，很麻烦。链式队列的销毁遍历要小心：先保存下一个节点的指针，再 free 当前节点，顺序反了，你就永远找不到下一个节点了。

4. 让代码跑起来最容易翻车的地方：空队、最后一个节点与野指针

4.1 为什么“删最后一个元素”会成为灾难现场

我前面写过一个看起来不起眼、实际上非常关键的判断：出队时如果被删节点恰好是尾节点，需要把 rear 拉回到 front。

不写这个判断会出现什么后果？我用一个具体场景模拟：

队列初始为空，执行三次入队操作，假设节点地址分别是 A、B、C。此时 front 指向头结点 H，rear 指向 C。如果连续三次执行出队：

• 第一次出队删除 A，front->next 变成 B，rear 仍然指向 C，状态正常。
• 第二次出队删除 B，front->next 变成 C，rear 仍然指向 C，状态正常。
• 第三次出队删除 C，front->next 变成 NULL，但 rear 仍然指向 C，而 C 的内存已经被 free 掉了。

从逻辑上讲，此时的队列是空队列，因为 front 和 rear 没有指向同一个头结点，isEmpty(Q) 会返回 false。更可怕的是，你如果再执行 enQueue 操作，代码会向已经释放的 C 节点内存中写入 next，然后让 rear 指向新节点。大多数时候这段内存没有被重用，程序还能勉强运行；一旦内存被操作系统或其它指针复用，就会出现莫名的段错误。

这个 bug 最阴险的地方在于，它不会在“删除最后一个元素”这一时刻立即暴露，而是推迟到下一次入队时才崩溃。写单元测试的时候，如果只测入队、出队各自独立的功能，不测“清空后再次入队”的场景，很难发现它。

4.2 空队列到底长什么样：头结点带来的统一视角

带头结点的队列中，空队列的形态是 front == rear 并且都指向头结点。这带来一个非常清爽的结论：空队列中的所有操作都可以通过这个简单的判断来拦截。

出队前用 isEmpty 判断，返回错误；取队头前用 isEmpty 判断，返回错误。不带头结点的方案在那个时刻 front 和 rear 都变为 NULL，isEmpty 等于 front == NULL，看起来也简洁。但一旦要把队列传给多个函数处理时需要重置，麻烦就来了。带头结点的好处是，无论队列经历多少次“从空到非空再到空”的状态变化，front 和 rear 始终指向同一个稳定地址，不需要额外处理“NULL 指针”。

4.3 用三组用例验证你的队列实现

我曾经在训练营里带学员，要求大家实现链式队列后必须跑完下面这组测试用例。这一组用例覆盖了中代码里最容易出错的全部边界条件，全部通过才说明你的实现是可靠的：

第一组，基础操作：初始化后判断 isEmpty，应为 true；依次入队 1、2、3，然后连续出队三次，应为 1、2、3；最后 isEmpty 为 true。第二组，清空后重用：先入队 1、2，出队后清空队列，再重新入队 4、5、6，再出队，预期是 4、5、6，这个用例专门排查清空函数是否把 rear 复位了。第三组，空队列出队和取队头：初始化后直接调用 deQueue 和 getHead，预期返回失败，不能崩溃；这组用例如果崩溃，问题多半在退出条件写错，或者队列头结点本身没初始化好。

第三组测试里，失败返回的判空逻辑也要验证：程序应该打印“队列为空，操作失败”这样的提示，而不是静默跳过去。很多同学写这些函数时忘了返回值设计，出队函数直接写成 void，空队列调用时就是纯未定义行为，这对工程质量来说是坏习惯。

5. 链式队列和循环队列的选型之争：数据规模会说话

5.1 顺序队列的“假溢出”是从哪来的

学习链式队列时，很多人会想：用数组实现队列是不是更简单？确实，数组实现队列的最初版本非常直接：申请一个定长数组，用 head 指向队头，tail 指向队尾的下一位置。

但很快会发现问题：如果有七次入队、三次出队，head 会慢慢向后挪，队头前面空出来很多位置，后面继续入队却可能已经越界了。明明数组前半部分是空的，队列却报“已满”，这就是“假溢出”。

要解决假溢出，常见的办法是循环队列：下标通过取模运算环绕回数组开头。但是循环队列又引入了新的困扰——怎么区分队空和队满。因为 front 和 rear 相等既可以是空队列，也可能是队列恰好满了，必须用额外的手段区分：牺牲一个存储单元、记录元素个数、或者加标志位。

这些都不是难懂的问题，但揭示了顺序队列在应对动态变化时的僵硬感：容量必须事先确定，扩缩容要频繁搬移数据，队空队满的边界条件要在多个细节上做文章。

5.2 一张表看明白链式队列和循环队列的差异

链式队列也不是银弹。它在灵活性上远超顺序队列，每次入队都会申请新的节点内存，相应的内存分配开销不可避免。以下是我在实际开发时常用的对比维度：

这个表并不绝对。比如在嵌入式环境里内存是稀缺资源，每个节点多出的 next 指针可能成为压垮骆驼的最后一根稻草；而当你处理一个服务器上的并发任务队列时，任务数量常常剧烈波动，链式结构反而更合适。选型不是背课文，而是问自己：我的数据规模是已知还是未知？我的运行环境允许动态申请内存吗？我的场景更在意单次操作的稳定还是整体吞吐？

5.3 并发环境里的队列：选型更重要的是可控性

如果你开始接触多线程和线程池，你会发现 Java 的 LinkedBlockingQueue 和 ArrayBlockingQueue 并没有谁绝对优于谁，而是看使用场景。线程池的工作队列如果选无界队列，当任务提交速度超过处理速度时会无限堆积，最终占用大量内存，导致服务假死。如果选有界队列，当队列满了之后，线程池会触发拒绝策略，把任务挡在外面，这种“宁可拒绝，也不能无限积压”的思路，在生产者消费者模型中非常常见。

链式队列的“无界”特性在单线程教学里很舒服，因为不需要考虑容量上限。但到了并发框架里，有界性本身就是一种保护机制。这也是为什么我建议你在学数据结构阶段就多想想“容量”的问题——数据结构不是只在算法题里运行，它会被放进真实系统里接受极端流量的考验。

6. 把链式队列放回真实系统：它远不止一道课后题

6.1 阻塞队列：给链式队列加上锁和条件变量

链式队列学完之后，向上走一步就能接触到“阻塞队列”。概念上它还是队列，入队出队的规则没变，只是增加了一套并发协作机制：队列空时，出队线程等待，不能返回错误；队列满时，入队线程等待，不能无限插入。

Java 里的 BlockingQueue 接口有很多实现，LinkedBlockingQueue 底层本质就是一条链表加一把锁和两个条件变量。你用单线程实现的链式队列，相当于把锁的部分去掉后的核心逻辑。理解了这个递进关系，再回头看我前面那套入队出队代码，会对“队列是线程池内部任务缓冲”这句话有更具体的认识。线程池里的核心线程如果都在忙，新来的任务会进入工作队列等待；一旦有线程空闲，就从队列里取一个任务执行。这套机制和你在餐厅排队等位一模一样，只是换成了线程和任务。

6.2 从数据结构队列到消息队列：不要混淆抽象层级

很多初学者学完队列，会立刻联想到互联网上常说的“消息队列”，以为用链表实现一个 FIFO 结构就等同于做了消息中间件，这个理解需要纠正。

数据结构课里的队列解决的是“进程内、方法内、单机内”的元素排队问题。而消息队列（比如业务系统里常见的各种 MQ 产品）解决的是“跨服务、跨节点、异步解耦与削峰填谷”的系统问题。两者的核心思想确实一脉相承——先进先出、生产者把消息放进来、消费者按顺序取出。但消息中间件还拥有数据持久化、消费确认、失败重试、集群高可用、顺序保证、重试与死信处理等一系列机制。

关于消息队列场景中经常被问到的“重复消费”问题，我想额外说一点：队列本身通常只能保证消息被投递给消费者，却很难保证消费者只处理一次。这是因为消费者处理成功后还没来得及提交确认就宕机了，消息会被重新投递。要解决重复消费，不能只靠队列，还需要消费者在业务上做幂等控制。这种“底层数据结构只能解决一部分，上层协议解决另外一些”的思维模式，恰恰是计算机系统设计中最值得训练的部分。

6.3 如果只记一个应用场景：树的层序遍历和迷宫最短路径

在没接触图和树之前，队列最直观的应用是二叉树的层序遍历：从根节点开始，先把根节点入队；然后循环取出队头节点，访问它，再把它的左右孩子依次入队。这个过程保证了同一层的节点会连续被访问，一层结束再处理下一层，天然符合广度优先搜索的思路。

想体验队列真正的威力，可以自己实现一个迷宫最短路径问题：把起点入队，在队列不为空时取出队头坐标，尝试向四个方向扩展，把合法并且没走过的邻居入队。由于队列的先进先出特性，所有距离起点一步的格子会先被访问，然后是两步的格子，以此类推。第一次扩展到终点时，走过的步数一定是最少步数。如果不使用队列而改用栈，得到的结果很可能是绕来绕去的一条路径，而不是最短路径。这就是我在动手实践时最想分享的收获：数据结构不只是代码模板，它是某些算法成立的前提，广度优先之所以用队列，正是因为它依赖“逐层推进”的顺序。

我自己在后来的项目里写过一个简化的任务批处理器，刚开始用的就是这章实现的链式队列思路，后端再套一层并发控制。链路不复杂，但它让我彻底和队列这个结构熟了。建议你也一样，今天照着代码敲一遍，把三个测试用例跑通，再把第四章那个“删除最后一个元素后继续入队”的场景亲手触发一次、修复一次，比你只看完这篇文章有用得多。下一轮可以继续往前推进，把循环队列、优先队列、双端队列等变体逐个吃透，也可以进入树的学习，因为树的层序遍历正好需要队列来铺路。