链表基础与LeetCode实战：从指针原理到虚拟头结点应用

算法训练营进行到Day 3，话题从数组切到了链表。很多人在数组阶段还能跟着节奏走，一到链表就开始晕——代码不长，逻辑也不算特别复杂，但“指针指来指去”的过程在脑子里就是转不过弯。这篇文我会把Day 3链表part01的三块核心内容——链表理论基础、LeetCode 203移除链表元素、LeetCode 707设计链表——完整拆开，讲清楚每一处设计背后的理由，并把我自己实际调试中踩过的坑一并列出来。内容主要面向正在刷LeetCode的初学者、准备实习面试的在校生，也适合那些链表操作写过就忘、想系统过一遍基本功的读者。

1. 链表训练营第三天的内容版图：为什么链表是算法面试的常驻嘉宾

数组和字符串属于“线性结构的入门”，链表紧接着出现是有原因的。链表题看似简单，却特别能暴露一个人对引用和指针的理解程度。很多面试官喜欢用链表题来快速判断候选人的代码基本功——你可以背下很多模板，但链表的操作一旦脱离画图辅助，全靠脑子里的指针推导时，很容易当场翻车。这也是训练营把链表单独拆成两天来练的原因，基础不牢，后面做树和图会更痛苦。

1.1 链表不是“数组plus”，是另外一种存储思维

链表和数组从存储层面就是两种思路。数组在内存里是一段连续的存储空间，下标可以直接计算地址，所以随机访问特别快，时间复杂度O(1)，代价是插入和删除一个元素时，为了保持连续，后面的元素全部要往后或往前挪，平均是O(n)。链表不一样，每个节点是单独分配的内存，节点之间靠指针串起来。它在内存中的位置可以东一块西一块，只要每个节点记录好下一个节点的位置，整条链就能完整遍历。

生活化一点的比喻：数组像电影院里的连排座位，票上写了第几排第几座，你按号找就行。链表像一串寻宝纸条，每张纸条上只写着下一张纸条藏在哪里，你必须从第一张开始一张一张找下去。这个本质区别决定了后续所有操作的复杂度差异，可以整理成一张对比表：

理解了这个对比，你就知道为什么链表的题目从来不会让你“算下标”，而是让你“顺着指针走”。训练营里反复强调的一句话是：链表的所有操作，本质上都是指针操作。

1.2 单链表、双链表、循环链表：三天内要区分清楚的事

链表分三种：单链表、双链表、循环链表。单链表每个节点只有一个next指针，只能从前向后遍历，Day 3的题目基本都基于单链表。双链表每个节点有prev和next两个指针，可以双向遍历，删除节点时能够直接拿到前驱，不用再从头找。循环链表则是尾节点的next指向头节点，形成一个环，在需要循环访问的场景里会用到。

初学者不需要深挖三种结构的全部实现，但至少要能在纸上画出它们的结构图。尤其是双链表里“通过prev找前驱”这件事，会在后面部分题目里出现。链表操作中有一句很核心的话：你能操作的粒度，取决于你能拿到哪些节点。比如单链表删除时必须知道被删节点的前驱，因为只有前驱的next能指向被删节点的后继；双链表就不需要这个前提，因为被删节点自己有prev。这个区别是很多综合题的考察点。

1.3 链表定义代码里的隐藏考点：构造函数与节点结构

很多初学者刷链表题时会直接复制模板里的ListNode定义，但没细想过这段代码背后藏着什么。C++的单链表节点通常是这样定义的：

cpp复制struct ListNode {
    int val;
    ListNode *next;
    ListNode() : val(0), next(nullptr) {}
    ListNode(int x) : val(x), next(nullptr) {}
    ListNode(int x, ListNode *next) : val(x), next(next) {}
};

构造函数重载看起来不起眼，但在本地调试时非常关键。如果只写了 ListNode(int x) 这一个构造版本，后面想写 new ListNode(0, head) 这种创建虚拟头结点的代码就会直接编译报错。我见过不少初学者卡在这个细节上，以为是链表逻辑写错了，其实是构造函数缺了一个参数版本。Python版本的定义相对简洁：

python复制class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next

这里的核心点是next默认值设为None，创建单个节点时不需要额外关注它，后面把这些节点串成链时才需要手动赋值。

2. 移除链表元素：虚拟头结点的意义你在调试时才能体会

LeetCode 203题要求删除链表中所有值等于给定val的节点，返回新的头节点。题目本身不难，但它是链表操作的第一道坎，因为它刚好踩在所有初学者最不熟悉的点上：链表的删除到底发生了什么。很多人在数组里删除元素习惯了“覆盖元素”的思维，到了链表里还在想怎么“擦掉”这个节点，方向就偏了。

2.1 删除链表节点的核心机制：改指向不等于删内存

链表删除节点的动作，本质上只是把“上一跳”改到“下下家”。假设链是A -> B -> C，想删掉B，只需要让A.next从B变成C，B就被“摘下来”了。但这里要区分两个层面：逻辑删除和物理释放。逻辑删除就是改变指针指向，这是算法层面关心的；物理释放是把不再使用的节点内存还给操作系统，这是C++工程里必须关心的。

在LeetCode的提交里，C++代码如果不delete被摘下来的节点，通常不会立刻报错，甚至能顺利通过测试。但这不是好习惯。一旦到了真实工程环境，每次删除都泄漏一块内存，程序跑久了内存占用会持续增长。删除节点时的正确顺序是：先让pre.next指向cur.next，再delete cur。这里有一个检查自己是否理解到位的小问题：如果先delete cur，再改pre.next，会发生什么？答案是cur.next已经不可访问，代码直接崩溃。操作的先后顺序在这里是生命线，不是锦上添花的细节。

2.2 不设虚拟头结点的写法：为什么总在头节点处理上翻车

先看不使用虚拟头结点的代码，你才能感受到为什么后面要引入它。常规思路是维护一个pre指针在前，cur指针在后，遍历整个链表：

cpp复制ListNode* removeElements(ListNode* head, int val) {
    while (head != nullptr && head->val == val) {
        ListNode* tmp = head;
        head = head->next;
        delete tmp;
    }
    ListNode* cur = head;
    while (cur != nullptr && cur->next != nullptr) {
        if (cur->next->val == val) {
            ListNode* tmp = cur->next;
            cur->next = tmp->next;
            delete tmp;
        } else {
            cur = cur->next;
        }
    }
    return head;
}

这段代码逻辑是对的，但有几个让人不舒服的地方。第一个while是专门处理头节点的，因为头节点没有前驱，删除它和删除中间节点的方式完全不一样。第二个坑是：如果删掉头节点之后，新的头节点仍然等于val，你还需要继续删，所以必须是while而不是if。同样的逻辑在中间节点部分又要注意：删除完一个中间节点后，cur不能急着往后移动，因为新的cur->next可能也是要删除的节点。你会发现，同一个“删除后要继续判断”的逻辑，在两处用了不同方式处理，代码的对称性被打破了，阅读和调试的负担明显增大。

2.3 加一个 dummyHead 之后，代码为什么立刻清爽了

虚拟头结点的思路很简单：在真正的头节点前面再挂一个傀儡节点，它的next指向head。这样原来的头节点就变成了一个普通节点，删除操作再也不用单独分类讨论。

cpp复制ListNode* removeElements(ListNode* head, int val) {
    ListNode* dummyHead = new ListNode(0, head);
    ListNode* cur = dummyHead;
    while (cur->next != nullptr) {
        if (cur->next->val == val) {
            ListNode* tmp = cur->next;
            cur->next = cur->next->next;
            delete tmp;
        } else {
            cur = cur->next;
        }
    }
    ListNode* result = dummyHead->next;
    delete dummyHead;
    return result;
}

这段代码和上一版对比，最大变化是：统一的删除逻辑、不需要单独处理头节点、不需要在删除后对头节点做二次判断。整个循环里只有一种判断：cur->next存不存在，它的值等不等于val。这里也解释一下为什么删除后cur不移动：因为cur->next可能又指向一个新的、同样需要删除的节点，如果cur直接前移，就会漏掉这一轮判断。这个细节和上面的非dummy版本本质相同，但放在统一逻辑里更不容易写错。

提示：很多资料把虚拟头结点叫dummyHead、sentinel或者pseudoHead，名字不重要，只要心里清楚它是一个不承载真实业务数据的占位节点就行。

3. 设计链表：这道综合题是你链表基本功的照妖镜

LeetCode 707题要求自己实现一个链表类，题目会规定好接口，你只需要把它们全部实现。很多人在写203的时候觉得链表不过如此，到了707才发现自己远没真正理解链表——因为它把链表的全部基础操作拉通考了一遍。203只是单方向的删除操作，707则把增、删、查、改全都覆盖了，任何一个环节的状态没维护好，其他接口都会跟着出问题。

3.1 先把接口想清楚：题目要你实现什么，删减不得

707题的接口一共有五类：

• get(index)：获取链表中下标为index的节点的值，下标从0开始，下标无效返回-1。
• addAtHead(val)：在链表头部插入一个值等于val的节点，插入后新节点成为第一个节点。
• addAtTail(val)：在链表末尾追加一个节点，值等于val。
• addAtIndex(index, val)：在下标为index的节点之前插入节点；如果index等于链表长度，直接追加到末尾；如果index大于链表长度，什么都不做；如果index小于0，插入在头部。
• deleteAtIndex(index)：删除下标为index的节点，下标无效则什么都不做。

题目还给了很贴心但容易忽略的约束：节点数量在操作过程中始终处于可控范围，不会出现极端内存问题。这个约束意味着你用单链表实现就足够通过，不需要去写双链表。接口数量看起来多，但每个单独实现的难度都不大，真正的难点在于共享一套数据结构时，任何一个接口里的size或者next没维护好，都会污染其他接口。707考的不是你会不会写某一个函数，而是你有没有能力设计一套自洽的数据结构。

3.2 核心实现：size 变量和链表长度的关系

这道题最核心的设计决策，是统一使用一个虚拟头结点，并维护一个整型变量size来记录链表长度。为什么需要size？因为get和deleteAtIndex需要判断index是否合法，addAtIndex需要判断index和size的关系。如果不维护size，每次都要遍历一遍链表数节点，复杂度从O(1)退化成O(n)，代码还容易出错。

size的维护规则很简单：在每一个会修改链表结构的操作里同步增减。addAtHead、addAtTail、addAtIndex成功插入后size加1，deleteAtIndex成功删除后size减1，get不改变size。很多人写707翻车，不是某一个接口写错了，而是某个接口里漏掉了size++或size--，导致后面的操作全部基于错误的size运行，查错要查半天。

下面是完整实现，所有插入和删除都通过dummyHead统一处理：

cpp复制class MyLinkedList {
private:
    int size;
    ListNode* dummyHead;

public:
    MyLinkedList() {
        size = 0;
        dummyHead = new ListNode(0);
    }

    int get(int index) {
        if (index < 0 || index >= size) return -1;
        ListNode* cur = dummyHead->next;
        while (index--) cur = cur->next;
        return cur->val;
    }

    void addAtHead(int val) {
        ListNode* node = new ListNode(val);
        node->next = dummyHead->next;
        dummyHead->next = node;
        size++;
    }

    void addAtTail(int val) {
        ListNode* cur = dummyHead;
        while (cur->next != nullptr) cur = cur->next;
        cur->next = new ListNode(val);
        size++;
    }

    void addAtIndex(int index, int val) {
        if (index > size) return;
        if (index < 0) index = 0;
        ListNode* cur = dummyHead;
        while (index--) cur = cur->next;
        ListNode* node = new ListNode(val);
        node->next = cur->next;
        cur->next = node;
        size++;
    }

    void deleteAtIndex(int index) {
        if (index < 0 || index >= size) return;
        ListNode* cur = dummyHead;
        while (index--) cur = cur->next;
        ListNode* tmp = cur->next;
        cur->next = cur->next->next;
        delete tmp;
        size--;
    }
};

addAtHead里有一个顺序问题值得单独说。node->next要先指向原来的头节点，再把dummyHead->next改成node，顺序不能反。如果先把dummyHead->next改成node，原来的头节点地址就丢了，新节点就变成一个孤立节点，整条链表直接断开。addAtTail每次都要从头遍历到尾节点，时间复杂度是O(n)，这道题的规模下完全够用。如果你想优化，可以在类里额外维护tail指针，但那样插入和删除时都要多考虑tail的更新，复杂度成倍上升，Day 3阶段我建议先把基本版本吃透再说。

3.3 每个操作的边界条件：index 合法性的规范判断

707的边界条件是最容易丢分的地方。deleteAtIndex的合法性条件与get完全一致：index >= 0 && index < size。addAtIndex的合法性判断特殊一点：index > size时什么都不做，index == size时插入到末尾，index < 0时插入到头部。为什么允许index == size？因为在尾部追加本身就是addAtIndex(index == size)的语义，这是题目明确规定过的。

这里要警惕一个不对称：deleteAtIndex和get都不允许index == size，因为下标从0开始，合法最大下标是size - 1，size位置没有节点；但插入操作可以插在size位置，因为这个位置是“链表末尾之后”。很多人第一次写707都会在这里栽一次，我也一样。我当时在addAtIndex里把判断写成了index >= size就return，结果index == size时应该尾部追加，却被我直接丢掉了，提交后直接报错。后来我把三个函数的边界条件列在同一张表里对照，才彻底记住：

写707之前，建议先在纸上把这张表填好，再开始写代码。边界条件想清楚之后，这道题就只剩下机械实现。

4. 实操中我踩过的坑：指针/引用问题的排查思路能省你一小时

链表的题目代码量不大，但调试起来特别折磨人。数组可以用下标直接看到任意位置的元素，链表不行。一旦指针关系错了，你面对的是一个断开或者成环的未知结构，打印都只能从头开始。这一章我把自己在C++和Python两个版本上踩过的典型问题整理出来，应该能帮你少走很多弯路。

4.1 Python 版本的引用陷阱：节点对象别乱改

用Python写核心插入操作是这样：

python复制class MyLinkedList:
    def __init__(self):
        self.dummy_head = ListNode()
        self.size = 0

    def add_at_index(self, index: int, val: int) -> None:
        if index > self.size:
            return
        if index < 0:
            index = 0
        cur = self.dummy_head
        for _ in range(index):
            cur = cur.next
        cur.next = ListNode(val, cur.next)
        self.size += 1

看起来和C++版几乎一样，但Python有一个特别容易踩的引用陷阱。很多人会把“移动cur”和“修改链表”两件事混为一谈。判断标准很简单：凡是带=且左边是cur =的，都只是让cur换一个指向，不会改动链表结构；凡是带=且左边是cur.next的，都是在真正改动链表结构。

还有更隐蔽的共享对象问题。如果你创建节点时把同一个节点对象插入了多个位置，那么在修改其中一个位置时，所有指向这个对象的引用都会受到影响。平时写链表很少遇到这个问题，但在写链表反转或者其他需要复用节点的操作时，一个节点被多个指针指向是很常见的，这时就要想清楚：你改的是对象本身，还是只是对象的引用关系。Python的垃圾回收机制会帮你管理内存，但它不会帮你判断逻辑上的引用关系，这块必须自己掌握。

4.2 C++ 版本的内存细节：delete 与野指针

C++版本最常见的两个坑：忘记释放被删除节点的内存，以及释放之后没有把指针置空，留下野指针。删除节点的标准动作是：

cpp复制ListNode* tmp = cur->next;
cur->next = tmp->next;
delete tmp;

两个细节值得展开。第一，不要在改了cur->next之后再去取tmp->next。如果你先执行cur->next = cur->next->next，但之前没有把原cur->next保存到tmp，那就再也拿不到被删节点的地址了，删除操作会留下一个悬空的内存块，造成泄漏。正确顺序是：先保存要删的节点为tmp，再改写指针，再释放tmp。

第二，delete tmp之后，tmp本身变成无效指针，但它仍然可以被用来比较或赋值。为了避免野指针带来的潜在崩溃，工程上通常建议立刻加上tmp = nullptr;。在LeetCode的用例里，由于局部变量用完就销毁，这个细节不一定会触发bug，但作为训练营学员，我更建议每次delete后都养成置空习惯，后面做更复杂的工程题时会少踩很多坑。如果你用debug模式跑C++代码，野指针的报错通常表现为随机崩溃，很难稳定复现，这也是链表调试最头疼的地方。

4.3 一个调试技巧：用 print_trace 把链表状态打出来

链表题调试的痛点是“看不见”。我的建议是：在工具代码里准备一个通用的链表打印函数，每次有疑问就在操作前后各打印一次。C++版本：

cpp复制void printList(ListNode* head) {
    ListNode* cur = head;
    while (cur != nullptr) {
        cout << cur->val;
        if (cur->next != nullptr) cout << " -> ";
        cur = cur->next;
    }
    cout << endl;
}

Python版本：

python复制def print_list(head):
    cur = head
    values = []
    while cur:
        values.append(str(cur.val))
        cur = cur.next
    print(" -> ".join(values))

这个函数的价值不在于它有多难写，而在于你愿不愿意在写每道链表题前都先准备好。我在练707的时候，每个操作之后都print一下，一共打印了十几遍，每次都能立刻发现size有没有同步、next有没有接错。确认所有操作正确之后再把print删掉提交，比盯着屏幕空想要高效得多。

如果你发现代码在LeetCode上超时了，第一反应不应该是优化复杂度，而是检查链表里是不是出现了环。常见的成环原因是删除或插入时，某个节点的next没有正确更新，导致遍历永远走不到nullptr。用printList打印，如果同一个值反复出现，八成就是环了。

5. 练完Day 3之后，我建议你这样巩固链表基础

训练营的节奏很快，一天一个part，当天掌握和隔天遗忘之间往往只差一个主动复习的动作。链表这一块尤其需要趁热打铁，因为指针操作的肌肉记忆形成得慢，但一旦形成，后面做树、图、堆这些结构时会轻松很多。

5.1 三板斧练习法：背框架、画图、复现

我推荐一个“三板斧”的巩固方法。

第一板斧是背框架。这里的背不是死记硬背整个代码，而是把dummyHead和size这两个核心设计的存在理由背进潜意识：

cpp复制private:
    int size;
    ListNode* dummyHead;

每次看到链表题，第一反应先想这个框架：需要虚拟头结点吗？需要维护size吗？把这两条判断好，思路的地基就打好了，后面填充逻辑只是执行问题。

第二板斧是画图。链表的操作很难在脑子里凭空转起来，但画图能帮你把指针跳转变成视觉路径。画法很简单：画出几个节点，标出它们的地址和next指向，在纸上走一遍插入或删除的每一步。这个方法看起来笨，但对解决“顺序写反”这类问题是最高效的。

第三板斧是复现。第二天起床后再把Day 3的代码盲写一遍，不参考任何资料。第一遍能写个大概，第二遍能写完整，第三遍就会变成肌肉记忆。链表题至少连续写三天，才能真正做到条件反射式地使用dummyHead和size。这和健身是一个道理，一次练到位不如每天练一点。

5.2 下一个节点：part02 主要练什么

Day 3的part01把链表的基础操作全部过了一遍，part02会进入更综合的题型，包括两两交换链表中的节点、删除链表的倒数第N个节点、链表相交、环形链表II。这几道题几乎都会用到今天打下的地基。

举一个简单的关联：删除链表的倒数第N个节点，用快慢指针可以一次遍历完成，但如果你已经熟练掌握了dummyHead加计数法的思路，理解快慢指针方案时就不会被边界条件带偏。环形链表II需要判断链表是否有环，也会用到今天反复练的“链表中某个节点的next是否指向了已访问节点”的思维。

我自己的体会是，进入part02之前，最好先确保能独立默写出707的完整代码。不要急着赶进度，基础操作没有形成肌肉记忆就直接硬刚综合题，大概率会卡住。训练营的节奏虽然快，但自己的复习节奏可以灵活调整，慢即是快这四个字，用在链表这一part非常合适。

最后再分享一个小建议：链表题的代码量真的很小，翻来覆去无非是改next、维护size、判断边界这三件事。真正拉开差距的，是你对引用关系的理解深度，以及调试时能不能冷静地把状态打出来看。Day 3学完，如果你能独立把203和707都写对，并且能讲清楚每一步为什么这么写，你的链表基础就已经比大多数刷题刷到一半就放弃的人扎实了。