饭点一问“吃什么”，脑子就开始宕机；作业复习敲到 LinkedList，脑子同样宕机。这两天我把数据结构里最常用的链表重新过了一遍，顺手把之前一直没敢摸透的调试器也练到顺手。说真的，“LinkedList 和 DEBUG”放在一起，完全是天生一对——你写完 addFirst、remove、reverse，没跑之前觉得自己写的都是神作，一 debug 就发现空指针、死循环、尾节点丢失全冒出来了。这篇就是我的 LinkedList 复习笔记和 debug 实战记录，不绕弯子，直接讲我怎么从“吃什么”联想到“用什么结构”，又是怎么把链表这个练基本功的东西彻底搞定的。如果你是那种链表一跑就崩的人，这篇应该对胃口。
提示：标题里的“吃什么”指的不只是外卖，更是“这道题应该吃什么数据结构”。文章里所有代码都以复习场景为主，你可以直接照着写。
1. 先把“吃什么”翻译成技术选型
写代码和点外卖有个共同点：你得先知道自己想要什么。外卖选不好顶多难吃一顿，数据结构选不好就要多 debug 三个小时。LinkedList 在作业里出现频率非常高，但很多人（也包括当年的我）只是照着 API 一顿调，真到手写或分析复杂度时，就露馅了。
1.1 为什么链表总是出现在作业里
数据结构作业安排 LinkedList，通常不是为了让你背“LinkedList 里面有 addFirst、addLast”这些方法，而是要训练指针和引用操作的基本功。链表节点之间靠 next（以及双向链表里的 prev）串成一条链，操作一个节点时还要照顾头节点、尾节点和空链表这些边界。老师选链表题，本质上是在考你会不会考虑“边界条件”和“内存关系”。
很多同学平时用 Java 或 C++ 标准库里现成的链表，方法一调就好，完全不用关心底层。但作业一旦要求手写，或者要求分析“反转链表”“判断链表是否有环”“合并两个有序链表”这类变形题，问题就全来了。所以复习 LinkedList，不能只背方法名，得从节点结构开始把整条链在脑袋里重新搭一遍。
1.2 链表和数组到底差在哪：停车位与寻宝线索
要选对数据结构，先得把链表和数组的区别揉碎了讲。下面这张表是我复习时反复看的：
| 维度 | 数组 | 链表 |
|---|---|---|
| 存储方式 | 连续内存空间 | 节点分散，靠指针连接 |
| 随机访问 | 按下标访问，O(1) | 必须从 head 开始遍历，O(n) |
| 在已知位置插入/删除 | 需要移动大量元素，O(n) | 只需要修改前后指针，O(1) |
| 空间开销 | 基本无额外开销 | 每个节点多存一个或两个指针 |
| 缓存友好度 | 好，数据连续 | 差，节点地址可能相隔很远 |
我习惯用生活例子去记：数组像编号停车场，你知道车位号，走过去就行，随机访问非常快；但要在中间塞一辆车，后面的车全得挪一遍。链表像寻宝线索，你只拿到第一条线索，顺着 next 一个一个找，随机访问很慢；但往中间塞一条新线索，只需要改前后两张纸条的指向，不惊动其他纸条。
选型时问自己三个问题：是不是经常按下标取数据？是不是明确知道要插入的位置？对内存连续性和缓存有没有要求？答案不同，选择就不同。
1.3 别把 LinkedList 当万能钥匙
很多人看复杂度表，以为“链表插入是 O(1)”就很无敌。实际上，想在一个具体的链表位置插入，你得先通过遍历找到那个位置，整体开销还是 O(n)。更何况现代 CPU 对数组特别友好，因为数组加载时一次性连续读入缓存，而链表的节点地址分散，每走一步都可能缓存未命中。
真实项目里，Java 的 ArrayList 大多数场景都比 LinkedList 快，Java 官方文档自己也提示过 LinkedList 不一定适合频繁随机访问。链表真正的舞台在头部频繁增删、LRU 缓存、以及需要实现队列栈这类场景。作业复习时，可以先把“随机访问、按序访问、头部插入、已知位置插入”这几个操作画个表，再决定选什么结构。遇到题目先纠结“用什么”而不是“怎么写”，说明你已经摸到门道了。
2. LinkedList 核心知识点复习：从节点到指针
技术选型定好以后，就要把链表内部结构复习扎实。很多人 debug 链表时两眼一抹黑，是因为脑子里没有节点和指针的实时画面。下面从节点开始一层层拆。
2.1 节点：链表的最小单位
链表的基本单位是节点，一个节点至少包含两部分：数据和指向下一个节点的指针。C 或 C++ 里通常写成结构体：
struct Node { int value; Node* next; Node(int v) : value(v), next(nullptr) {} };Java 版本就是内部类：
private static class Node { int value; Node next; Node(int v) { value = v; next = null; } }为什么叫 next 而不是别的名字？因为每个节点只负责告诉你去哪找下一个节点。头节点 head 是整个链表的入口，只要 head 丢了你全串就没了。链表里的每个节点都是单独 new 出来的，地址在内存里基本不相邻，这一点和数组完全不同。所以在调试器里看链表时，你会看到一堆十六进制地址，比如head = 0x5b60048a、head->next = 0x5b600490。不要被这些地址吓到，它们其实是你的“寻宝线索”。
2.2 增删改查的具体实现与边界条件
复习链表，动手写一遍增删改查比背十遍理论有用。我常用的是带泛型思想的简化版本，先看核心方法：
public void addFirst(int v) { Node node = new Node(v); node.next = head; head = node; } public void addLast(int v) { if (head == null) { head = new Node(v); return; } Node cur = head; while (cur.next != null) { cur = cur.next; } cur.next = new Node(v); } public boolean contains(int v) { for (Node cur = head; cur != null; cur = cur.next) { if (cur.value == v) { return true; } } return false; }这里有几个特别容易踩的边界：
- addFirst 时，必须先让新节点的 next 指向旧 head，再把 head 更新为新节点。顺序反了，旧链表就丢了。
- addLast 时，如果链表为空，新节点就是 head，不能直接 while 循环，否则空指针。
- 遍历链表的循环条件到底是
cur != null还是cur.next != null？找尾节点用cur.next != null，处理每个节点用cur != null。两个循环停下的位置不一样，这也是 debug 时最容易懵的地方。
删除操作我再给一个常用技巧：虚拟头节点。很多人写删除头节点时，需要单独判断if (head.value == v)，容易乱。加一个 dummy 节点可以让逻辑统一：
public void remove(int v) { Node dummy = new Node(0); dummy.next = head; Node prev = dummy; Node cur = head; while (cur != null) { if (cur.value == v) { prev.next = cur.next; break; } prev = cur; cur = cur.next; } head = dummy.next; }虚拟头节点最大的好处是：所有节点都变得“有前驱”，头节点不再特殊。这对 debug 和面试都很有用，强烈建议背下来。
2.3 双链表和循环链表的扩展点
如果作业里用到 Java 的LinkedList，它里面其实是双链表，节点同时有 prev 和 next 两个指针。双链表的优势是删除当前节点时不用刻意找前驱：
node.prev.next = node.next; if (node.next != null) { node.next.prev = node.prev; }但注意第二个赋值前一定要判断node.next != null，否则尾节点会空指针。循环链表则是把最后一个节点的 next 指向 head，遍历结束的条件不再是cur == null，而是cur == head，最好再加一个计数器防止死循环。复习时如果先吃透单链表，再补双链表的 prev 更新，遇到循环链表也不会慌。
3. DEBUG 才是 LinkedList 的正确打开方式
链表为什么非要 debug？因为它的结构是动态的，每一个 next 赋值都可能把链子接错。我见过太多人对着代码看半小时，也找不出问题，一上调试器十秒钟就定位了。下面是我实测下来最顺手的 debug 流程。
3.1 先建一个最小可复现环境
不要直接在大作业里翻来覆去打断点。我每次复习链表，第一步都是建一个单独的小测试文件，造一条 1 -> 2 -> 3 的链表，然后只改一个操作，观察一次输出：
public static void main(String[] args) { LinkedList list = new LinkedList(); list.addLast(1); list.addLast(2); list.addLast(3); list.print(); // 期望 1 -> 2 -> 3 list.addFirst(0); list.print(); // 期望 0 -> 1 -> 2 -> 3 list.remove(2); list.print(); // 期望 0 -> 1 -> 3 }如果第二行输出不对，问题大概率在 addFirst；如果第三行不对，重点查 remove。最小可复现的好处是缩小搜索空间，不会让你在一个 1000 行的作业里从头猜到尾。这个方法不仅适用链表，几乎所有算法作业都适用。
3.2 调试器里盯住三个关键点
正式开始 debug 时，不要漫无目的地看变量。我只关心三个东西：
- head 指向哪里，值是多少。
- 每个节点的 next 是不是正确指向下一个节点。
- 当前遍历指针 cur 到底是停在 null、头节点还是某个中间节点。
在 VS Code 里，可以在行号左侧打上断点，然后在“监视”面板添加cur、cur.next、head.value这些表达式；在 gdb 里对应的命令是p *cur、p cur->next->value。没调试器的时候，也可以用条件断点，比如当cur.value == 666时停下来，能直接跳过大量无关节点。
我还习惯在链表类里记录一个size字段，每次 add/remove 同步更新。debug 时只要看一眼 size 对不对，就能快速判断是不是多插了或少删了。
3.3 日志打印和断言配合使用
不是什么时候都能友好地打断点，尤其在线判题系统里，唯一的输出通道就是打印。所以我专门写了一个带安全上限的打印函数：
private void printList(String action) { System.out.print(action + ": "); Node cur = head; int step = 0; while (cur != null) { System.out.print(cur.value + " -> "); cur = cur.next; if (++step > 100) { System.out.println("[可能成环]"); return; } } System.out.println("null"); }这个函数本身就是防死循环的 debug 利器。加上计数器上限后，就算链表真的成环，程序也不会一直打印到天荒地老。关键操作前还可以加断言，C/C++ 里是assert(cur != nullptr);，Java 里是Objects.requireNonNull(cur);。日志告诉你“走到哪一步挂了”，断言告诉你“不该出现的情况出现了”，两个配合能省太多时间。
3.4 改完代码还是老结果？先验明正身
复习时有一个超级常见的坑：你明明改了代码，但运行结果还是旧的。这不一定是你链表逻辑写错，而是环境问题。我的排查顺序是：
- 看构建状态：IDE 里有没有报错，有没有自动编译失败。
- 重启调试会话：有些运行中的进程不会自动加载新代码。
- 清掉中间产物目录（比如 project out / build / target），重新编译。
如果还是不对，就在入口第一行加一个临时输出print("enter debug")，确认程序真的跑到了新代码。很多“断电后是旧代码”的诡异现象，其实都是当前执行环境还在用旧产物，别急着怀疑数据结构代码。
4. 常见问题与排查技巧速查表
链表 debug 的问题看似千变万化，其实归纳下来就那么几类。这一节我把踩过的坑和排查思路整理成速查表，下次写完链表再遇到问题，直接对照着查。
4.1 空指针与空引用
| 症状 | 可能原因 | 排查思路 |
|---|---|---|
| java.lang.NullPointerException | 链表为空，head 为 null，却访问了 head.next | 打印 head 判断是否为空，循环前判空 |
| C++ 段错误 SIGSEGV | cur 已经是空指针，还在访问 cur->next 或 cur->value | 在循环体开头加 assert，或打断点看 cur |
| 操作某个节点的 next 时崩溃 | 节点本身为 null，或上一轮操作把引用断开了 | 画一下从 head 到目标节点的路径，确认中间没有空引用 |
最容易踩的循环条件问题是：遍历到最后一个节点后，cur 已经变成 null，但代码又在循环体里访问cur.next。记住一句话——用cur != null处理当前节点；用cur.next != null找尾部节点。两者不能混用。
4.2 头节点丢失和尾节点不更新
头节点丢失最常见的表现是：addFirst 之后打印链表，发现少了一大截。原因多半是忘记把新节点的 next 指向旧的 head，或者直接让 head 指向新节点但新节点 next 还是 null，等于把原链表地址全丢了。
尾节点不更新的问题则更隐蔽。如果你在类里单独维护了一个tail字段，addLast 时只写了tail.next = new Node(v)，却忘了把tail更新成新节点，下一次 addLast 还是会从头遍历，而且 tail 一直指向旧尾节点。我的经验是：凡是维护 head 或 tail 字段，增删操作里一定要同步更新。最稳妥的做法是写一个统一的addNode(Node node)方法，把头部、尾部、中间插入的逻辑都收拢到一起，减少漏改。
4.3 死循环与环检测
链表成环以后，现象是程序卡住、CPU 狂转、容量监控一路飙升。最常见的成因是某个节点的 next 被错误地指向了自己，或者在插入时把同一个节点接回了链表中。
判断链表是否有环，先别急着用复杂算法，直接在打印函数里加步数上限，看是不是走到了上限。如果确实怀疑有环，可以用经典快慢指针：
Node slow = head; Node fast = head; while (fast != null && fast.next != null) { slow = slow.next; fast = fast.next.next; if (slow == fast) { System.out.println("链表有环"); break; } }快指针每轮走两步，慢指针走一步，如果有环，两者一定会在某个节点相遇。这个技巧也会频繁出现在作业和面试题里，复习链表时顺手掌握很划算。
4.4 删除节点后的内存问题
手写链表时，C/C++ 最让人头疼的就是内存管理。删除节点时，顺序错一步就会导致整条链段掉，或者 double free。正确顺序是先接线、再释放：
Node* tmp = cur->next; // 先保存下一个节点 prev->next = tmp; // 让前驱跳过当前节点 delete cur; // 再释放当前节点 cur = nullptr; // 随手置空一定要先修好前驱和后继的关系，再去 delete。Java 里虽然不用手动释放内存，但也要注意别让不必要的引用继续存在，否则对象无法被回收。写作业时如果发现内存占用越来越高，多半是循环里不断创建节点但没有断开旧引用，或者链表成环后无法被回收。
4.5 我的 debug 顺序：先画、再打印、后断点
最后分享一下我个人的调试顺序。很多人一上来就开 IDE 打断点，其实效率不高。我更喜欢先用笔在纸上画出 head、每个节点和 next 的指向，然后模拟执行一次操作。比如删除节点 2，我会先把节点 1 的 next 画到节点 3，再划掉节点 2。画对了，代码基本不会差太远。
画完图以后，如果程序能跑，就调打印函数看输出。只有打印看不出来的时候，才上断点去看某个具体步骤。这个顺序对新手特别友好，因为画图逼着你把链表结构在脑子里“跑起来”，很多 bug 会在落笔的瞬间暴露。我自己 debug 链表时经常以为自己改了 head.next 就够了，画完图才发现 head 指针已经指向了错误位置，这种问题只靠眼睛盯是根本盯不出来的。
这次复习下来，我反倒更想把 LinkedList 当成一块试金石。它不像排序那样吃数学，也不像图论那么抽象，它考的就是你愿不愿意认真处理细节。“吃什么”这个问题的答案，往往不是某道菜有多出名，而是你了解它有多少；LinkedList 也一样，不是头节点加 next 指针有多复杂，而是你要不要花时间把边界和调试方法啃下来。
我最后再分享一个实际有用的习惯：每次写链表题，我会强制自己先打印一遍长度和首尾节点的值，再让程序继续跑。就这一招，已经帮我拦下过至少三次低级 bug。如果你看了这篇也能顺带把“调试器里看节点”这个技能练熟，那这次 LinkedList 的作业复习就算值了。
