从数组的局限性理解链表的诞生动机1.1 数组这个“老实人”的三处软肋我第一次接触链表时的反应和很多初学者一样数组用得好好的非要搞个链表出来这不是自己给自己找麻烦吗等真正动手写程序、遇到实际业务场景之后我才明白数组这个看起来最自然的数据结构其实藏着三处绕不过去的软肋。第一处软肋是容量固定。声明一个数组的时候必须提前告诉编译器“我要多少格空间”比如int arr[100]。可实际数据量往往不是预先能估算准的你预估收 50 个报名表结果来了 500 个人你预估日志文件最多撑到 1 万行结果某天流量暴涨涨到 10 万行。这时候数组要么不够用要么提前申请了大片空间却一直闲置。扩容也不是不行把旧数组内容复制到新数组再释放旧空间但数据量一大这个复制动作本身就是沉重的开销。第二处软肋是中间插入和删除的成本高。想象一排连续的座位坐满了人突然有个人要站到第 3 个位置上。你没办法凭空把他塞进去必须让第 3 个位置以及后面所有人都往后退一格。删除同理要补上那个空位后面的人全部前移。放到数组上就是往中间插入一个元素平均要移动 n/2 个元素删除一个元素也要移动差不多的数量。数据少的时候无所谓数据上万之后这种“集体搬家”就非常痛苦。第三处软肋是内存必须连续。数组要求一整块连续的内存空间。机器内存里连续空间往往是稀缺资源——你可能明明还剩余 2GB 内存但分散成几十个小块就是找不出一块能容纳 500MB 连续数据的区域最终结果是无法分配。这在嵌入式、内存碎片严重的环境里尤其让人头疼。带着这三个问题再看链表就有一种“对症下药”的感觉它不要求连续内存每个数据节点单独存放用指针互相串联插入和删除只需要改指针不需要搬动其他元素想要多少节点就动态申请多少天然支持不确定的数据规模。可以说理解链表价值的最好方式不是先背概念而是先把数组的痛点亲手体验一遍。1.2 “手拉手排队”与“固定座位观影”链表到底改变了什么用生活化的方式去理解数组和链表的本质差异我比较喜欢这个类比数组是一间按固定座位排好的电影院链表则是一列手拉手站队的人。电影院每个座位都有固定的坐标第 3 排第 5 座就在那儿报上编号你一秒就能过去坐下。这就是数组的随机访问能力——arr[i]直接能定位时间开销为 O(1)。但代价是座位和座位是物理上绑死的有人插队后面所有人都得挪。链表则相反队列里的人可以站在操场上任何位置只要每只手紧紧拉住下一个人队伍就不会散。想插队从前面找到那个位置把两个人的手断开让新人同时拉住两个人改一下“指针”就完成站在后面的人完全不用动。但代价也很明显你想找第 100 个人必须从第 1 个人开始一个一个顺着拉手的链条数过去没人能瞬间跳到第 100 个访问某个特定位置的耗时是 O(n)。这就是链表带来的核心思想转变把“物理位置上的连续”替换成“逻辑上的串联”用内存上的自由换取访问上的不便利用插入删除的高效率弥补随机访问的短板。后面我们会看到这个“换取”到底值不值全看业务场景是读多写少还是写多读少。链表不是数组的替代品它们只是两种不同代价的组织方式理解了这个出发点后续上手写代码时就不会总想着“为什么链表这么麻烦”。链表的结构秘密节点、指针与头节点的坑2.1 节点就是“数据 线索”链表的基础单位叫节点英文是 Node。每个节点要承担两件事装自己的数据以及告诉别人“下一个节点在哪里”。所以一个节点最少包含两个部分数据域和指针域。用 C 语言定义就是这样的结构体struct Node { int data; // 数据域保存实际数据 struct Node *next; // 指针域指向下一个节点 };这里的data可以换成任意类型字符串、结构体甚至其他复杂对象都行next则是一个指向struct Node类型变量的指针它存的是下一个节点的内存地址。多个节点通过next一环扣一环地串起来就形成了链表。最后一个节点的next必须指向NULL表示“到这里队伍就结束了”。很多初学者看到“指针”两个字就打怵其实这里不需要管指针有多少复杂的花活只需要记住一点指针就是“告诉你去哪找”的地址。就像每一个同学知道下一个同学站在操场的哪个方位顺着那个方位就能找到人。指针赋值p-next q的意思就是“从 p 这个地方出发下一个要去的地方是 q”。把概念落实成代码之前建议先自己画一张图一个方框分成上下两格上格写数据下格写指向然后用箭头把方框连起来。链表题目里各种指针操作的核心本质上就是如何在纸上改箭头走向这个脑内模拟能力会陪你走完全程。2.2 单链表、双链表、循环链表三种串联方式对比链表不是只有一种形态。最常见的是单链表Singly Linked List也就是每个节点只有一个next指针只能从前往后走不能回头。你能从第 1 个节点走到第 2 个、第 3 个但走到第 5 个之后想回第 3 个没办法只能重新从头部开始再走一遍。双链表Doubly Linked List在此基础上增加了一个prev指针保存前一个节点的地址。这样一来从任意节点出发既能往后走也能往前走很多操作方便了很多。代价是每个节点都要多存一个指针内存占用更大插入删除时需要维护的指针数量也翻倍代码复杂度随之上升。循环链表Circular Linked List则是把链表的尾节点和头节点连起来单链表的最后一个节点的next不指向NULL而是指回头节点双链表则同时让头节点的prev指向尾节点。这样整个链表形成一个环从任何节点出发都能遍历完全部节点。日常业务里循环链表用得不算多但它特别适合“轮流循环访问”的场景比如操作系统的进程轮询、某些游戏里的轮流出牌逻辑。用一个表格对比一下三者的特点类型方向性删除末尾节点效率内存开销典型场景单链表只能向后需要从头遍历到末尾前一个效率低每节点 1 个指针栈、邻接表、内存池双链表双向通过prev直接定位效率高每节点 2 个指针LRU 缓存淘汰、浏览器前进后退循环链表环形视起点而定每节点 1 或 2 个指针约瑟夫问题、轮询调度2.3 头节点 vs 头指针最容易被绕晕的一对概念链表新手最容易翻车的概念之一就是“头节点”和“头指针”到底有什么区别。我见过不少初学者在讨论代码时把这两个词混着说结果连自己写的程序哪里出的错也理不清。简单来说头指针是变量头节点是节点对象。头指针head pointer是一个指针变量它存的是链表中第一个节点的地址。如果链表为空头指针就是NULL。而头节点head node可以有两种含义一种是“哨兵节点”dummy node它本身不存实际业务数据只是作为链表的第一个占位节点用来统一对空链表和非空链表的操作另一种是“第一个数据节点”。在很多链表的教材代码里会默认设计一个“不存数据”的头节点。为什么要这样因为有了一个永远存在的头节点每次插入、删除时就不用单独判断“链表是不是空的”“我删的是不是头节点”这些边界情况。刚开始写链表代码的人可能体会不到这个设计的妙处等你写删除操作时需要处理“删除第一个节点”和“删除中间节点”两套逻辑写着写着你就会认同一个占位的头节点能省掉多少if。我自己练习链表的时候建议先分清楚自己写的是哪种形态带头节点的单链表还是无头节点的单链表。这两种形态的代码逻辑略微不同混用会把自己弄晕。选定一种把所有题目都在这个形态下做完回过头再对比另一种理解边界情况就顺理成章了。手写一个单链表增删查改的完整实现3.1 定义节点C 语言结构体怎么设计理论知识聊再多不如亲手敲一遍代码。下面我用带头节点的单链表为例完整演示一遍增删查改的全过程。为什么选带头节点的写法因为它在实际工程里实现起来最不容易出错逻辑最统一。第一步定义节点结构和链表本身的结构#include stdio.h #include stdlib.h // 定义链表节点 struct Node { int data; struct Node *next; }; // 定义链表为了方便管理保存链表长度 struct LinkedList { struct Node *head; // 指向头节点哨兵节点 int length; // 链表中实际数据个数不含哨兵节点 };我习惯用LinkedList这个包装结构把“头指针”和“链表长度”放在一起。维护一个显式的长度字段可以在很多操作中避免为了数个数而完整遍历一遍链表比如“查第 k 个节点”时如果 k 大于 length就可以直接报错省去一次无效遍历。初始化链表也很直观// 初始化链表创建哨兵节点 void initList(struct LinkedList *list) { list-head (struct Node*)malloc(sizeof(struct Node)); list-head-next NULL; // 哨兵节点不存数据next 指向空 list-length 0; }这里哨兵节点的data字段没有被赋值也不需要赋值因为它只是一个入口占位符代表“链表从这里开始”。它存在的意义是无论链表是否为空head指针永远有效这样后续在头部插入、删除时就不需要特殊处理空表情况。3.2 头插法与尾插法两种构建链表的姿势构建链表时最常用的两种方式是头插法和尾插法。头插法把新节点插在哨兵节点之后也就是链表的第一个数据位尾插法则把新节点追加到整个链表的末尾。先看头插法void insertAtHead(struct LinkedList *list, int data) { struct Node *newNode (struct Node*)malloc(sizeof(struct Node)); newNode-data data; newNode-next list-head-next; // 新节点指向原来的第一个数据节点 list-head-next newNode; // 哨兵节点指向新节点 list-length; }这段代码只有三步却几乎包含了所有链表插入操作的本质先让新节点“拉住”原来队伍的第二个位置再让队伍入口“拉住”新节点。顺序很关键——必须先改新节点的next再改 head 的next。反过来写就会丢掉原链表后面一整串节点的地址造成“断链”后面再想找回它们就难了。尾插法则需要先遍历到链表的末尾void insertAtTail(struct LinkedList *list, int data) { struct Node *newNode (struct Node*)malloc(sizeof(struct Node)); newNode-data data; newNode-next NULL; struct Node *cur list-head; while (cur-next ! NULL) { cur cur-next; } // 此时 cur 指向最后一个节点 cur-next newNode; list-length; }注意遍历的终止条件cur-next ! NULL循环结束时 cur 正好停在最后一个节点上。如果写成cur ! NULL循环结束后 cur 已经变成NULL再去操作cur-next就踩到了野指针这是新手常犯的一个低级但致命的错误。头插法时间复杂度只有 O(1)尾插法平均需要 O(n) 的遍历。所以如果允许颠倒顺序通常更倾向于用头插法构建链表如果必须保持输入顺序则要么用尾插法要么额外维护一个tail尾指针把尾部操作也优化成 O(1)。3.3 遍历、查找与删除操作链表的核心套路有了插入自然就要有遍历输出这是验证链表结构是否正确的“仪表盘”void printList(struct LinkedList *list) { struct Node *cur list-head-next; while (cur ! NULL) { printf(%d - , cur-data); cur cur-next; } printf(NULL\n); }遍历的核心套路就是用一个临时指针 cur 从第一个数据节点开始每访问一个节点就把 cur 指向它的 next直到遇到 NULL 停止。这个套路会贯穿所有链表操作包括查找和定位删除。按位置查找节点本质是“走 k 步”struct Node* getNode(struct LinkedList *list, int pos) { if (pos 1 || pos list-length) { printf(位置越界\n); return NULL; } struct Node *cur list-head-next; for (int i 1; i pos; i) { cur cur-next; } return cur; }删除指定位置的节点则需要拿到“目标节点的前一个节点”因为删除的本质是“让前一个节点跳过目标节点直接指向目标节点的下一个节点”void deleteAtPosition(struct LinkedList *list, int pos) { if (pos 1 || pos list-length) { printf(位置非法无法删除\n); return; } struct Node *cur list-head; // 找到目标节点的前一个节点需要走 pos-1 步 for (int i 1; i pos; i) { cur cur-next; } struct Node *target cur-next; // 目标节点 cur-next target-next; // 前一个节点跳过目标节点 free(target); // 释放目标节点内存 list-length--; }删除操作里最容易忘记也最关键的不是改指针而是free(target)。链表节点是动态申请出来的不释放就会造成内存泄漏但释放之后又不能再通过target-next去访问数据。所以正确顺序是先把target-next保存或先让前一个节点完成接管再 free。我在带新人看代码的时候经常说一句链表操作的本质是“先接线、后拆线”顺序搞错轻则丢数据重则程序崩溃。下面把完整示例串起来跑一遍int main() { struct LinkedList list; initList(list); insertAtHead(list, 10); insertAtHead(list, 20); insertAtTail(list, 30); insertAtTail(list, 40); printList(list); // 20 - 10 - 30 - 40 - NULL deleteAtPosition(list, 2); // 删除第 2 个节点值为 10 printList(list); // 20 - 30 - 40 - NULL struct Node *node getNode(list, 2); if (node ! NULL) { printf(第 2 个节点的值: %d\n, node-data); // 30 } return 0; }4.1 单链表删除尾节点为什么这么别扭单链表写顺之后你会开始遇到一些“明明能实现、但总觉得不对”的场景删除尾节点就是最典型的一个。在单链表里要删除最后一个节点必须把倒数第二个节点的next置为NULL可你手里只有一个head只能从头部开始一个一个找。找倒数第二个节点意味着要走 n-2 步时间复杂度 O(n)。如果说删除尾节点还算可以忍受那在双向场景里就会更尴尬你通过某个节点的指针已经走到了链表的尾部此时想删除它却发现在单链表里根本拿不到它的前驱节点只能从头再来。这个别扭的根源就是单链表“只能前进、不能后退”的天然缺陷。解决思路也很直白给每个节点再加一个前驱指针也就是从单链表升级成双链表。删除尾节点在双链表里就变得非常舒服。我先用文字描述操作逻辑再放代码找到尾节点tail把tail-prev也就是倒数第二个节点的next置为NULL释放tail。每一步都只需要操作两个节点跟链表总长度没有关系时间复杂度是 O(1)前提是能直接拿到尾节点的引用。这背后体现的就是“空间换时间”的思想用每个节点额外 8 字节一个 64 位指针的内存开销换来了删除效率从 O(n) 降到 O(1)。4.2 双链表用空间换时间的典型双链表的结构定义相比于单链表多一个prev指针struct DNode { int data; struct DNode *prev; // 指向前一个节点 struct DNode *next; // 指向后一个节点 };双链表的插入和删除操作核心是“同时维护两条链”。比如在节点p后面插入一个新节点newNode需要四步让newNode-next指向p-next让newNode-prev指向p如果p-next不是NULL让p-next-prev指向newNode最后让p-next指向newNode。注意“如果p-next不是NULL”的条件判断很多人第一次写双链表插入时会漏掉对尾节点后面是NULL的判断直接把p-next-prev赋值结果解引用空指针程序立刻崩溃。双链表的实际应用场景很多最经典的是 LRU 缓存淘汰算法。LRULeast Recently Used的基本逻辑是数据被访问过就移动到链表头部链表尾部就是最久没被访问的数据需要淘汰时直接删除尾部节点。这个场景要求“快速移动到头部”和“快速删除尾部”两者都需要删除任意节点的能力而单链表做不到 O(1) 删除一个只知道自身地址的节点双链表可以——因为每个节点都知道自己的前驱是谁。不少刚接触 LRU 的开发者会不理解“为什么必须双链表哈希表组合”实际上双链表解决的是“快速删除”哈希表解决的是“快速查找”两者缺一不可。4.3 循环链表当最后一个节点重新指向开头如果单链表的尾节点不再指向NULL而是回头指向头节点整个链表就变成了一个环这就是循环链表。同样地双链表也能做成双向循环链表也就是尾节点的next指向头节点头节点的prev指向尾节点。循环链表最大的优势是从任意节点出发都能遍历到全部节点。这在处理轮询类场景时特别顺手。比如多个客户端轮流连接服务器的任务调度用循环链表会很自然当前位置走到下一个位置一直在环里打转没有边界要处理。经典的约瑟夫问题Josephus Problem也是循环链表的教科书级应用。假设 n 个人围成一圈从第 1 个人开始报数报到 m 的人出列然后从下一个人继续报数直到只剩一个人问剩下的那个人原来在哪个位置。用循环链表来做非常直观节点就是人出列就是删除节点因为链表是环形的删除后天然从下一个节点继续开始不需要处理“到达尾部回到头部”的边界逻辑。核心代码片段长这样struct Node *josephus(struct Node *head, int m) { struct Node *cur head; while (cur-next ! cur) { // 只剩一个节点时它自己指向自己 // 报数 m-1 次因为当前节点也算一次 for (int i 1; i m - 1; i) { cur cur-next; } // 此时 cur-next 就是报数为 m 的节点 struct Node *toDelete cur-next; cur-next toDelete-next; free(toDelete); cur cur-next; // 从下一个节点继续报数 } return cur; }这里的循环终止条件cur-next ! cur也值得留意当环里只剩一个节点时它的 next 指向自己这既是循环链表“首尾相连”的自然结果也是判断“是否只剩一个元素”的优雅方式。如果用普通链表实现约瑟夫问题处理“绕圈回来”的逻辑会额外繁琐循环链表则把这种繁琐消解在了数据结构自身的设计里。4.4 三种链表的选型对照把三种链表放在一张表里选择的时候我的思路通常很简单先看业务需不需要“后退”再看会不会形成环。场景特征推荐类型原因只需要从头部顺序往后处理数据单链表最简单内存开销最小需要频繁删除“当前已知的某个节点”双链表前驱可查删除 O(1)需要反复绕圈轮询、循环调度循环链表天然环形无边界处理浏览器前进后退、文档撤销重做双链表或双向循环链表双向移动操作 O(1)注意这些选型并不是绝对的。比如某些嵌入式环境内存极其紧张即使业务上需要双向移动也可能退而求其次选择单链表加“从头遍历寻找前驱”的折中方案。工程权衡没有银弹一切都要看约束条件。链表和数组的取舍别只会背时间复杂度5.1 一张表看清数组和链表的差异面试和实际开发中数组和链表的对比几乎不会缺席。与其背一堆“8 字口诀”不如自己把这张表推一遍理解每一个结论从哪里来维度数组链表内存布局连续内存大小固定节点分散动态增长随机访问O(1)arr[i]直接算地址O(n)必须从头遍历头部插入O(n)所有元素后移O(1)改两个指针头部删除O(n)所有元素前移O(1)改指针并释放尾部插入O(1)如果有空闲容量O(n)需遍历到尾维护尾指针可 O(1)中间插入O(n)移动元素O(1)找到位置后改指针内存利用需要一整块连续区域可能浪费或分配失败碎片内存也能用但有指针存储开销缓存友好度高局部性原理受益低节点跳跃访问扩容成本高复制整个数组天然动态扩展这张表里最反直觉的一点是数组在“中间插入”这一项竟然是 O(n)而链表在“找到位置的前提下”是 O(1)。但注意括号里的前提——找到位置本身链表依然要 O(n)。所以严谨的说法是链表在“已知插入位置节点引用”的条件下插入是 O(1)如果只知道下标插入的复杂度依然是 O(n)。很多面试者栽在这一句话的严谨性上。5.2 缓存局部性理论快不等于实测快只背时间复杂度的最大问题就是会忽略一个现实理论复杂度相等不代表实际程序跑得一样快。现代 CPU 运行程序时内存读写不是一次只读一个变量的而是一块一块地从主存加载到高速缓存。数组是连续内存遍历时下一块数据大概率就在刚加载的缓存行里CPU 几乎不用等待这种特性叫缓存局部性。链表是分散内存每个节点可能相隔很远遍历时每次访问cur-next都得重新去内存寻址如果涉及缺页和缓存未命中性能会明显变差。所以你会看到一个有趣的现象在数据量较小时遍历链表的耗时可能数倍于遍历数组即使链表某些操作的复杂度理论上更优常数因子也可能吃掉优势。我实际测试过一个 100 万元素的数组和同样规模的链表各自做一次完整遍历数组的耗时要稳定地少几个数量级具体数值依赖机器和编译器但趋势几乎不变。这提醒我们数据结构选型永远要回到真实的硬件和业务约束条件里去谈而不是拿着复杂度表套一个“最优解”。5.3 实际场景里的选型经验那么实际开发中到底怎么选我从项目实践里总结出几条经验不一定放之四海皆准但可以当成讨论起点。读多写少、且需要频繁随机访问的场景优先用数组或者动态数组比如 Python 的 list、Java 的 ArrayList。典型例子是排行榜、配置表、静态数据存储。这类场景几乎没有中间插入的需求连续内存的缓存优势能发挥到极致。写多读少、尤其大量头部/中间插入删除的场景优先考虑链表。典型例子是任务队列、撤销历史、内存池管理。比如你在实现一个函数调用栈的状态记录频繁在头部入栈出栈链表比搬移数组元素优雅得多。需要快速头部和尾部同时操作的场景用双链表或带头尾标记的队列队列也可以用数组实现环形队列但大小动态变化时链表更灵活。LRU 这类“查改混合”的场景链表负责记录访问顺序哈希表负责快速定位两者配合而不是让其中某一种结构硬扛全部需求。结构选型的本质是“找到业务痛点再反推哪种结构的短板更能被接受”。我曾经在一个日志采集模块里起初用数组存待发送的消息队列结果不断有中间插入、删除和扩容问题调试成本居高不下后来改成带头尾指针的双链表逻辑一下子清爽了内存碎片问题也因为在节点上做了复用池而得到缓解。当然这里不是说链表就是银弹换一个读多写少的报表系统我还是会老老实实选数组。链表调试手记指针丢了、死循环和那些经典翻车现场6.1 三个高频翻车原因链表代码写起来不长调起试来却可能让人怀疑人生。回顾我带新人和自己做练习的经历翻车原因基本集中在三类。第一类断链。本意是把 A 节点的 next 指向 C把 B 插在中间却因为步骤顺序写反先改了链表的入口指针导致后面的节点全部丢失。这类错误的本质是没有在动手改指针之前想清楚哪条链还“欠着谁”。第二类空指针解引用。对NULL节点直接访问-next或-data常见于忘记判断链表是否为空、删除最后一个节点后还继续访问、遍历条件写错导致 cur 变成NULL后没有及时跳出。这类错误经常导致程序段错误Segmentation Fault调试信息还不一定指到出错的那一行。第三类死循环。链表里出现了环遍历永远走不完。最常见的原因是反转链表时没有保存下一个节点就改变了当前节点的 next或者循环链表的遍历终止条件没有写对。每次遇到这类现象我基本直接判断——某处指针被改成了回头路。6.2 一次反转链表的完整排错过程拿最经典的反转链表来做个完整的问题定位演示。错误版本长这样struct Node* reverseList(struct Node *head) { struct Node *prev NULL; struct Node *cur head; while (cur ! NULL) { cur-next prev; // 直接把 cur 的 next 改成 prev prev cur; // prev 前进到 cur cur cur-next; // cur 前进到下一步 } return prev; }看起来非常“符合直觉”每次让当前节点回头指向前一个然后前后指针一起前进。但跑起来就会陷入死循环。为什么因为第二步cur-next prev已经把cur的 next 改成了前一个节点相当于通往原来下一个节点的路已经被拆掉了第三步cur cur-next又顺着已经反转的next回退到上一个节点cur 永远在原地打转甚至倒退。正确的写法是先保存下一个节点的地址再改指针struct Node* reverseList(struct Node *head) { struct Node *prev NULL; struct Node *cur head; while (cur ! NULL) { struct Node *nextTemp cur-next; // 先保存原来的下一个节点 cur-next prev; // 再反转指针 prev cur; // 前驱前进 cur nextTemp; // 当前节点前进 } return prev; }调试这种 bug 时建议不要盯着代码干瞪眼拿出纸笔画三个节点的小样例标出每一步的 prev 和 cur 分别是谁。笔尖指到哪代码执行到哪最多画十步就能看出问题。我见过不少人花半小时调反转链表最后发现就是少了一行“先保存下一个节点”的结构性错误这类问题很适合用这种“手写模拟执行”的方式定位。6.3 链表调试的三条实用心法踩过的坑多了之后我总结出三条调试链表的实用习惯基本能解决 90% 的链表问题。第一条画画画。任何一次链表操作先画好“操作前”和“操作后”的两张图再用箭头标出哪几个指针需要被修改以及修改的先后顺序。图能画对代码的正确性就有了一半保证。第二条留意边界情况。写任何链表函数都习惯性地问三个问题链表为空时会怎样只有一个节点时会怎样操作位置在头部或尾部时会怎样我统计过新手提交的链表代码一大半的失败用例都挂在边界条件上尤其“只有一个节点时删除”“在头部插入/删除”这两类。第三条用好打印和断言。在关键位置打印当前指针、节点值或者用 assert 断言某个指针不为空都比闷头 gdb 来得快。小链表样例可以保证单步跟踪的清晰度大链表样例则用来验证没有栈溢出和死循环。如果接入开发板或嵌入式环境打印开销太大至少也要在关键 return 前留一个检查点。最后再分享一个我实践里的小技巧初学链表时不要直接在 IDE 里写 100 行代码再统一调试而是每写一个函数就立刻写一个 5 行的测试调用跑一遍打印结果。用“小步快跑”的方式把每个函数吃透再拼装完整逻辑你会发现自己踩坑的数量会断崖式下跌。链表这东西多写多调几天手感自然就来了坚持画图加边界检查这两条习惯后面学更复杂的数据结构时也会比旁人顺很多。