FFFire小火1. 为什么选择用C语言硬啃链表题
1.1 一个程序员对链表的执念
先交代一下背景。我前阵子把LeetCode Hot 100里的链表题刷了一遍，用的语言是C，不是C++也不是Python。这个选择在当时看来有点"自讨苦吃"，因为链表题在C++里有STL容器帮忙，在Python里更是有内置的list类型，代码写起来能短一半。但我坚持用C的原因很简单：链表这种数据结构，本质上就是玩指针，而C语言是把指针暴露得最彻底的语言。你用C写链表题，每一个->next都在你眼皮子底下，你不能靠语法糖和库函数掩盖自己对指针的不熟练。
刷完之后回头梳理，发现Hot 100里的链表题大概有十五道左右，虽然数量不算多，但覆盖面非常完整：反转、合并、环检测、相交、回文、排序、删除、两数相加，该有的题型全都有。而且这些题目之间是有递进关系的，掌握几道核心题型的套路后，剩下的都能套进去。这篇文章就是我的刷题日志，把每类题的核心思路、C语言实现时容易踩的坑、以及我自己的调试经验整理出来，给同样准备用C刷LeetCode的人做个参考。
1.2 面试和工程里的双重价值
有人可能会问：现在面试都允许用Python写算法题了，为什么还要练C的链表实现？我的看法是，链表在工程代码里出现频率虽然不高，但一旦出现，基本都是系统底层或者性能敏感模块，比如内核的任务队列、内存池的空闲块管理、哈希表的链地址法。这时候你如果只会调库，出了问题根本无从下手。
从面试角度讲，C语言写链表有几个隐性加分项：第一，你被迫手动管理内存，malloc和free的配对会让你更谨慎地思考节点的生命周期；第二，C语言没有std::shared_ptr这种东西兜底，悬空指针就是悬空指针，程序崩溃就是程序崩溃，这种压力能逼你形成肌肉记忆；第三，很多链表题的核心解法就是双指针和递归，用C实现时你需要自己控制所有细节，写出来的代码虽然长，但你对每一步的理解会深得多。我个人经验是，用C刷完链表题之后，再看C++和Python的写法，会有一种"俯视"的感觉。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Hot 100链表题的核心套路拆解
2.1 双指针技术：快慢指针的四种变体
链表题里最万能的工具就是双指针，我统计了一下，Hot 100链表题中大概有一半都能用双指针解决。快慢指针的变体主要有四种，我把它们整理出来：
第一种是"一快一慢"找中点，慢指针每次走一步，快指针每次走两步，当快指针到达链表末尾时，慢指针正好在中点。这个技巧在回文链表、排序链表里是基础操作。
第二种是"快先走N步"找倒数第N个节点，快指针先走N步，然后快慢指针一起走，当快指针到达末尾时，慢指针指向的就是倒数第N个节点。
第三种是"同速双指针"判断相交，两个指针分别从两条链表的头出发，走到末尾就跳到另一条链表的头，如果两条链表有交点，它们会在交点相遇，这个数学证明很有意思，本质上利用了"消除长度差"的思路。
第四种是"循环双指针"检测环，快指针每次走两步，慢指针每次走一步，如果链表里有环，两指针必定会相遇，而且相遇点还能用来推导环的入口。
我刚开始刷题的时候总想着每道题都要有新解法，后来发现其实就那么几种模式在反复用。你把这四种双指针变体吃透了，至少能解决一半的链表题。
2.2 虚拟头节点：一个被低估的工程思维
虚拟头节点（dummy head）在C语言链表题里的重要性，怎么强调都不过分。它的作用核心只有一句话：把"头节点可能被修改"的特殊情况消除掉。
举个例子，删除链表中倒数第N个节点，如果不加虚拟头节点，当N等于链表长度时，删除的就是头节点本身，这时候返回值需要特殊处理。加了虚拟头节点之后，逻辑就统一了：你总是在操作一个"前驱节点"的next指针，不需要判断删除目标是不是头节点。类似的场景还有：合并两个有序链表、反转链表前K个节点、按值删除所有匹配节点。
用C语言实现时，虚拟头节点有一个额外的好处：不需要处理malloc失败的情况——虽然实际工程中要处理，但刷题时malloc一个节点的开销几乎可以忽略。我在代码里习惯只写struct ListNode dummy;在栈上分配，不动态申请内存，这样省去了free的麻烦，代码也更简洁。
2.3 递归：反转链表背后真正的原理
很多人在刷反转链表这道题时，迭代法能写出来，但递归法总是觉得绕。其实递归写链表题，核心就一句话：你先相信我能够处理好以head->next为头的子链表，我只需要考虑如何把当前节点接到结果上去。
拿反转链表举例，递归写法是：
c复制struct ListNode* reverseList(struct ListNode* head) {
if (head == NULL || head->next == NULL) {
return head;
}
struct ListNode* newHead = reverseList(head->next);
head->next->next = head;
head->next = NULL;
return newHead;
}
这段代码的关键在head->next->next = head这一行。你不需要在脑子里完整展开每一层递归的调用栈，只需要记住：reverseList(head->next)返回的是"以head->next为头的那条子链表反转之后的新头"，而反转之后的子链表的尾节点恰好就是原来的head->next。所以head->next->next = head就是把当前节点接到子链表的尾部。
用C语言写递归时，要特别注意栈溢出问题。链表长度几百个节点没问题，但如果链表有几万个节点，递归调用栈可能撑不住。Hot 100里的链表题节点数通常不会太夸张，所以递归解法够用，但如果你在工程里处理超长链表，建议还是用迭代法。
3. 典型题目精讲与C语言实操
3.1 反转链表：迭代与递归的双重实现
反转链表（LeetCode 206）是链表题的"hello world"，几乎每家公司的面试题库里都有它。这题的目标很明确：把链表的方向全部反过来。
迭代法的思路是维护三个指针：prev、curr、next。每次迭代时，先把curr->next保存到next，然后把curr->next指向prev，再整体移动三个指针：
c复制struct ListNode* reverseList(struct ListNode* head) {
struct ListNode* prev = NULL;
struct ListNode* curr = head;
while (curr != NULL) {
struct ListNode* next = curr->next;
curr->next = prev;
prev = curr;
curr = next;
}
return prev;
}
这段代码的C语言实现有一个容易忽略的点：curr->next = prev这行执行完之后，curr和原来的链表就断开了，所以必须在断链之前把curr->next保存到next变量中。很多初学者会写成curr->next = prev; curr = curr->next;，结果发现curr根本没往后移动，因为此时curr->next已经是prev了。
我之前测试时发现一个问题：如果链表本身是环形链表，这个迭代函数会死循环。虽然LeetCode的测试用例不会给环形输入，但实际工程中调用反转函数前最好先检测是否有环。这是"防御性编程"的思维，刷题时可以不写，但你要知道边界在哪里。
3.2 环形链表：从相遇推导环入口
环形链表（LeetCode 141）和环形链表II（LeetCode 142）两题连在一起刷效果最好。141只要求判断有没有环，142要求找到环入口，后者比前者多了一步数学推导。
快慢指针判断环的思路特别直观：想象两个人在环形操场上跑步，一个人速度快，一个人速度慢，只要操场是环形的，两人一定会再次相遇。用代码实现就是快指针每次走两步，慢指针每次走一步：
c复制bool hasCycle(struct ListNode *head) {
struct ListNode *slow = head;
struct ListNode *fast = head;
while (fast != NULL && fast->next != NULL) {
slow = slow->next;
fast = fast->next->next;
if (slow == fast) {
return true;
}
}
return false;
}
142题的环入口定位就更有意思了。上面代码中快慢指针第一次相遇时，把快指针重新指向头节点，然后快慢指针都改成每次走一步，两个指针再次相遇的位置就是环的入口。这个结论很多人只知道背，不理解为什么。我花了一下午推导过一遍：
假设链表头到环入口的距离为a，环入口到相遇点的距离为b，相遇点到环入口的距离为c，那么环的长度是b+c。慢指针从出发到相遇走了a+b步，快指针走了a+b + k*(b+c)步（k是快指针绕环的圈数），因为快走的距离是慢的两倍，所以：
2*(a+b) = a+b + k*(b+c)
化简得到：a = k*(b+c) - b = (k-1)*(b+c) + c
当k=1时，a=c。也就是说，从头节点出发到环入口的距离，等于从相遇点继续走到环入口的距离。所以快指针从头出发、慢指针从相遇点出发，都是每次走一步，必然在环入口相遇。这个推导过程我建议你自己手写一遍，比单纯背结论牢靠得多。
3.3 合并K个有序链表：分治打败堆
合并两个有序链表（LeetCode 21）是基础题，合并K个有序链表（LeetCode 23）是进阶题。K个链表的解法有两个方向：一个是建一个最小堆，每次从堆顶弹出一个最小节点；另一个是用分治法，两两合并。
用C语言写堆有点痛苦，因为你得手写一个优先队列，需要维护上浮和下滤操作，代码量直接翻倍。所以我在Hot 100刷这题时选择了分治合并，写起来更直白：
c复制struct ListNode* mergeTwoLists(struct ListNode* l1, struct ListNode* l2) {
struct ListNode dummy;
struct ListNode* tail = &dummy;
dummy.next = NULL;
while (l1 != NULL && l2 != NULL) {
if (l1->val < l2->val) {
tail->next = l1;
l1 = l1->next;
} else {
tail->next = l2;
l2 = l2->next;
}
tail = tail->next;
}
tail->next = l1 != NULL ? l1 : l2;
return dummy.next;
}
struct ListNode* mergeKLists(struct ListNode** lists, int listsSize) {
if (listsSize == 0) return NULL;
int interval = 1;
while (interval < listsSize) {
for (int i = 0; i + interval < listsSize; i += interval * 2) {
lists[i] = mergeTwoLists(lists[i], lists[i + interval]);
}
interval *= 2;
}
return lists[0];
}
分治合并的时间复杂度是O(NlogK)，N是所有节点的总数，K是链表个数，这跟堆解法的时间复杂度一致。但是分治的空间复杂度更低：堆解法需要O(K)的额外空间存放堆结构，分治只要O(1)的额外空间。而且C语言里递归归并不会像堆那样需要动态扩容，实际跑起来代码更稳定。
3.4 回文链表：一道题串联三种技巧
回文链表（LeetCode 234）是Hot 100里综合性很强的一道题，它把找中点、反转链表和双指针比较三个技巧串在一起。题目要求判断一个链表是否为回文结构，比如1->2->2->1是回文，1->2->3不是。
解题思路分三步：第一步，用快慢指针找到链表中点；第二步，把中点之后的部分反转；第三步，从头和中点同时遍历比较节点值。我的C语言实现如下：
c复制bool isPalindrome(struct ListNode* head) {
if (head == NULL || head->next == NULL) {
return true;
}
struct ListNode* slow = head;
struct ListNode* fast = head;
while (fast->next != NULL && fast->next->next != NULL) {
slow = slow->next;
fast = fast->next->next;
}
struct ListNode* secondHalf = reverseList(slow->next);
struct ListNode* firstHalf = head;
struct ListNode* temp = secondHalf;
bool result = true;
while (temp != NULL) {
if (firstHalf->val != temp->val) {
result = false;
break;
}
firstHalf = firstHalf->next;
temp = temp->next;
}
reverseList(secondHalf);
return result;
}
注意这段代码里我最后把链表又反转回来了，这个操作在LeetCode上不是必须的，因为测试用例不会检查链表结构是否被修改。但如果是实际面试，恢复链表原状是一个非常好的加分项，面试官能看出来你考虑到了"函数的副作用"。C语言写这道题还有一个坑：while (fast->next != NULL && fast->next->next != NULL)这个条件少一个判断就可能对偶数长度链表找错中点，建议自己画一下节点数为偶数的链表走一遍流程。
4. 排序链表：归并排序的C语言实现
4.1 为什么不能用数组那套排序
排序链表（LeetCode 148）要求时间复杂度O(NlogN)、空间复杂度O(1)。看到O(1)空间复杂度，就排除了插入排序的直接套用和数组的快速排序。链表不支持随机访问，所以快速排序的分区操作在链表上做起来很难受。而归并排序天然适合链表：它只需要修改指针的指向，不需要移动节点本身的数据，这正是链表最擅长的操作。
归并排序链表的核心步骤也是找中点、递归排序、合并。找中点用快慢指针，递归排序左右两半，然后用mergeTwoLists合并。这个过程就是把单链表归并排序的思路搬过来。C语言实现时，关键是切链的操作：找到中点后要暂时把slow->next置为NULL，把链表切成两半，否则递归排序时两个子链表会互相干扰。
4.2 自底向上的归并排序怎么写
递归归并排序链表有一个隐患：递归深度是O(logN)，理论上没问题，但C语言的递归如果遇到极端情况（比如链表已经排好序），虽然归并排序不会退化成O(N)深度，实际深度也就是logN，所以栈溢出风险不大。
不过我在刷题时看到一个更优雅的写法：自底向上的归并排序。思路是先把链表拆成长度为1的子链表，两两合并成长度为2，再把长度为2的两两合并成长度为4，以此类推。这个写法不需要递归，代码稍微长一点，但省去了找中点的过程，对于超大链表的处理更稳。Hot 100对空间复杂度要求是O(1)，递归归并虽然辅助空间是O(logN)（递归展开的栈空间），但LeetCode的评测不会卡这么细，两种写法都能过。如果你追求完美，可以用自底向上版本，面试时还能主动解释两种写法的差异，这是加分表现。
5. C语言链表题常见错误与调试实录
5.1 Page Fault和段错误的产生原因
用C写链表题，最常见的运行时错误就是段错误，本质上是访问了非法内存地址。链表题里段错误的原因就那几样：访问了空指针的成员、访问了已释放的节点、循环链表导致遍历不终止。
我记得有一次调试两数相加（LeetCode 2）这道题时，用了malloc创建新节点，但是循环里漏了初始化next指针。结果返回链表时，遍历到最后一个节点后继续遍历，读到了垃圾地址，直接段错误。C语言里malloc出的内存内容是不确定的，不会自动置零，所以malloc之后一定要手动初始化每个字段：
c复制struct ListNode* node = (struct ListNode*)malloc(sizeof(struct ListNode));
node->val = sum % 10;
node->next = NULL; // 这行绝对不能漏
当时我就在想，如果在C++里用new，默认构造函数有时会帮忙初始化；在Python里直接用ListNode(val)根本不存在这个问题。所以用C刷题，每一行代码都要自己负责，这既是麻烦也是修炼。
5.2 调试链表题的三个实用技巧
链表题调试比数组题麻烦，因为数组可以随时printf整个数组，链表不能直接打印。我总结了一套调试方案：
第一，写一个通用的printList函数：
c复制void printList(struct ListNode* head) {
while (head != NULL) {
printf("%d -> ", head->val);
head = head->next;
}
printf("NULL\n");
}
这个函数在每道链表题里都可以复用。我一般放在本地代码的顶部，测试时直接调用，提交时会把它删掉。
第二，在关键操作前后分别打印一次链表，对比变化。比如反转链表，我在reverseList函数调用前后各打印一次，立刻能看出来反转是否生效、是否丢节点。
第三，用assert检查关键不变量。比如合并两个有序链表后，可以assert检查结果链表的每个节点是否都比前一个节点大或相等。这不是严格验证，但能快速定位问题区域。
5.3 内存泄漏怎么检查
LeetCode的C语言评测不会检查内存泄漏，但实际工程中，链表操作带来的内存泄漏很致命。一个节点丢失引用，这块内存就无法再访问，最终可能导致OOM。我刷Hot 100时会在本地编译时开启-fsanitize=address选项，它能检测堆内存泄漏和越界访问：
bash复制gcc -fsanitize=address -g solution.c -o solution
./solution
如果代码里有内存泄漏，程序退出时会输出详细的泄漏报告，告诉你泄漏的地址块大小和分配时的调用栈。这个工具我用下来感觉非常直观，建议所有用C刷题的人都装一下。删除链表节点时要记得free被删除的节点，反转链表时不涉及释放，但合并链表时要小心，如果函数内部malloc了临时节点，函数结束前一定要free掉。
6. 刷题路线与时间安排的建议
6.1 Hot 100链表题的推荐刷题顺序
很多刷题的新手犯的错误是打开Hot 100就从头开始按顺序刷，结果前面字符串题难度过高，直接就被劝退了。我的建议是分专题刷，链表是相对容易建立信心、且技巧复用性极高的专题。
我自己的顺序是：反转链表（206）和合并两个有序链表（21）先做，这两道是链表基本功；然后做删除链表的倒数第N个节点（19）和环形链表（141/142），这几道是双指针专项；接着做两两交换链表中的节点（24）和K个一组翻转链表（25），这两道是递归和指针操作的进阶；再做回文链表（234）和排序链表（148），综合前面所有技巧；最后做合并K个有序链表（23）和相交链表（160）作为收尾。
这个顺序的核心理念是"从单一技巧到综合技巧"。先让你在最简单的情景下熟练掌握反转和合并，再叠加双指针、递归等技巧，最后综合运用。每一步都建立在前面已经掌握的基础上，不会出现"这题解法我看都看不懂"的情况。
6.2 每天刷几道题合适
我自己是每天刷2到3道新题，加上1到2道旧题的复习。链表题不是刷完就完事的，一周后回头重新写一遍，往往会出现"当时明明会写，现在卡住了"的情况，这很正常，说明你的理解还在依赖短期记忆。我建议每题至少刷三遍：第一遍看题自己思考，尽力写一遍，然后看官方题解或者高赞题解，理解别人的思路，再用自己的话重写一遍；第二遍隔天重写，不看题解；第三遍隔一周重写，并且尝试用多种解法（比如反转链表分别用迭代和递归）。
链表题还有一个特点：代码长度不会太长，非常适合用来练手速和代码整洁度。我后来面试时，面试官让我手写反转链表，我几乎是条件反射就直接写出来了，边写边讲解思路，面试体验非常流畅。这种肌肉记忆就是靠多刷形成的。
6.3 C语言环境配置的小建议
热词里有人搜"vscode配置c/c++环境"，说明很多读者在用VSCode刷题。我自己的经验是用VSCode加gcc编译器就够了，调试用内置的GDB调试器。关键配置是tasks.json里的编译命令，记得加上-Wall -Wextra显示所有警告，这能提前捕获一些未初始化变量的问题。另一个建议是安装C/C++扩展后，开启"C_Cpp: Add Debug"模式下调试链表的可视化功能，调试时可以清楚看到每个节点的next指到哪里，比纯看代码直观太多。
如果你用的是CLion或者VS系列，也有对应的可视化调试工具，思路类似。用C刷题，调试器比print好用得多，特别是复杂的指针操作场景。
另外我再分享一个小技巧：刷链表题时，在草稿纸上画出链表结构图。我一般用圆圈表示节点，箭头表示next指针，每次操作改动指针时，用不同颜色的笔标记。这个方法看起来笨，但实际上对理解指针变动极其有效。电子设备上用画图板也可以，本质上是我前面说的"自己模拟一遍过程"的具象化操作。
7. 面试中链表题的答题套路
面试和刷题不太一样。刷题你自己闷头写就行，面试时你需要边写边说，让面试官理解你的思路。链表题特别适合展示一个人的思维过程，因为它的操作步骤是可分解的。
我的回答套路是这样：先说清楚题目要什么，然后讲清楚解法思路——用快慢指针还是虚拟头节点还是递归，为什么用这个方案，时间复杂度空间复杂度是多少。如果面试官没有打断，我就会继续介绍另一种解法，比如递归和迭代之间的取舍。很多时候面试官不会让你写完整个代码，你只要把思路讲明白，再写出关键几行，就已经很不错了。
链表题还有一个高频追问是："如果链表里有环怎么办？""如果链表节点数特别多怎么办？"刷Hot 100时就要有意识地把这些问题想清楚。比如反转链表，如果链表有环，迭代法会死循环，解决方案是先检测是否有环再反转；如果节点数特别多，递归法会爆栈，应该用迭代。这些思考在面试中非常加分，因为它们展示了你对边界条件的敏感度。
8. 一个多月刷完链表题的整体感悟
这段时间用C刷完Hot 100的链表题，最大的收获不是背下了十几道题的解法，而是建立了一种"指针直觉"——看到一个链表操作需求，能下意识地判断出需要几个指针、哪个指针该往前推进、哪个指针负责做操作。这种直觉很难用语言描述，但确实能让人在写链表代码时又快又准确。
如果你问我值不值得用C去刷这种对语法要求高的题，我的答案是值得，但要有心理准备。头几天肯定会有挫败感，因为一个段错误可能要找半小时。但你要相信，链表题的坑来来回回就那么几个，踩过一遍之后，后面越写越顺。等你用C把链表题刷完一遍，再回头看C++的std::list和Python的链表实现，你会真正明白它们帮你做了什么，你自己又能做到什么。这种感觉，只有亲手写过C链表的人才能体会。