环形链表与快慢指针：从判断有环到定位入环点

1. 这个知识点为什么值得死磕

说出来不怕大家笑话，我第一次在 LeetCode 上写环形链表这道题的时候，代码只写了二十行，自查了四十分钟，还是没搞明白为什么两个指针一定能相遇。后来拿张草稿纸一步一步画链表图，画了两页纸，才算把 Floyd 判圈算法的来龙去脉理顺。这也就是我想要用一整课来聊环形链表的原因——这个题目表面上是道"基础题"，但它背后涉及的思维模型、数学推导和边界处理，其实足够串联起一整套链表类的核心解题思路。

环形链表在面试里出现的频率有多高？我随便翻了翻近三年各大厂的算法面经，LeetCode 141 和 142 这两道题——也就是"判断链表是否有环"和"找到入环节点"——出现的概率排在整个链表分类的前三名。很多同学觉得它简单，因为解题代码确实不长，快慢指针两句话就写完了。但如果你真的把这道题讲透了，你会发现它考察的其实是三个层次：

• 第一层：会不会用哈希表做暴力解，明白它的空间复杂度为什么是 O(n)；
• 第二层：知不知道快慢指针这个最优解，以及为什么快指针每次走两步，而不是三步、四步；
• 第三层：能不能推导出"相遇点到入环点的距离等于头节点到入环点的距离"这个结论，并且用代码把它落地。

大多数博客只讲到第二层，把代码贴出来就完事了。但这恰恰是很多同学最迷茫的地方——面试官只要多追问一句"为什么相遇之后把快指针放回头节点，两个指针再同时走一步就一定在入环点相遇"，很多人就卡住了。这一课，我想把这三层全部拆开来讲，把推导过程、代码实现和面试追问全部理顺。

这篇文章适合谁看？如果你正在准备算法面试，或者正在学数据结构但被环形链表绕晕了，再或者你只是想知道哈希表和双指针思维到底差在哪里，这篇文章都能给你一个相对完整的答案。我会尽量用最直白的语言来讲，复杂的地方配合图示和推导，确保你看完之后不只是会背代码，而是真的理解了这个算法为什么这么设计。

2. 从"环是怎么来的"说起——理解链表的成环结构

2.1 单向链表为什么可能"走不出去"

先复习一下最基本的节点结构。单向链表里每个节点只有一个 next 指针，指向下一个节点。正常情况下，从 head 出发沿着 next 一直走，最终会遇到 null，链表就结束了。但有一种异常情况：某个节点的 next 指向了它前面的某个节点，那整个链表就形成了一个闭环，从 head 出发永远走不到 null，这就是所谓的"环形链表"。

举个具体例子，假设我们有一个链表：A -> B -> C -> D -> E -> C。注意，E 的 next 又指回了 C，而不是指向 null。那从 A 出发遍历，路径是 A -> B -> C -> D -> E -> C -> D -> E -> C...，永远在 C/D/E 这三个节点之间循环，链表没有一个合法的终点。这种结构在正常业务代码里通常是 bug——比如对象的引用关系意外成环，导致递归遍历或序列化时死循环。

2.2 环的核心特征：没有终点，且存在重复访问

判断一个链表有没有环，本质上就是在问一个问题：遍历过程中，会不会出现"同一个节点被访问两次"的情况。沿着这个思路往下想，最直觉的解法其实是：用一个哈希表（或者集合）把访问过的节点存下来。每走一步，先查一下当前节点在不在集合里——如果在，说明之前来过，链表有环；如果不在，就把当前节点加进去，继续走。如果走到了 null，说明链表没有环。

这个解法非常好理解，也非常好写，代码量大概就这样：

java复制public boolean hasCycle(ListNode head) {
    Set<ListNode> visited = new HashSet<>();
    while (head != null) {
        if (visited.contains(head)) {
            return true;
        }
        visited.add(head);
        head = head.next;
    }
    return false;
}

但问题在于空间复杂度是 O(n)，因为你需要把每一个遍历过的节点都存在集合里。对于一个节点数上百万的链表，这额外的内存开销是不容忽视的。所以面试官几乎一定会继续追问："能不能用 O(1) 的空间复杂度解决这个问题？"这个时候，快慢指针就该出场了。

2.3 快慢指针背后的直觉：跑步套圈

快慢指针的核心思想，生活里非常常见——操场跑步。想象两个人在圆形跑道上跑步，一个人跑得快，一个人跑得慢。如果他们同时出发，快的人总会比慢的人多跑几圈，然后在某个时刻追上慢的人——也就是"套圈"。如果跑道不是环形的，是一条直线跑道，快的人只会越来越远，永远不可能再次碰到慢的人。

把跑道的逻辑映射到链表上：慢指针每次走一步，快指针每次走两步，从 head 同时出发。如果链表有环，两个指针都会进入环内，快指针相对慢指针每次会多走一步，由于环是闭合的，快指针一定会从后面追上慢指针——两个指针在某个节点相遇。如果链表没有环，快指针会率先到达 null，循环自然终止，判定无环。

这个方案只需要两个指针变量，空间复杂度是 O(1)。代码也很简单：

java复制public boolean hasCycle(ListNode head) {
    if (head == null || head.next == null) {
        return false;
    }
    ListNode slow = head;
    ListNode fast = head.next;
    while (slow != fast) {
        if (fast == null || fast.next == null) {
            return false;
        }
        slow = slow.next;
        fast = fast.next.next;
    }
    return true;
}

注意这里我让 fast 初始指向 head.next，而不是 head。为什么这么写？因为如果用"先走再判断"的循环结构，初始 fast = head，slow = head，第一次循环条件 slow != fast 就是 false，循环根本进不去。所以要错开一步。当然也可以让 fast 也等于 head，把循环改成 do-while 结构，两种写法都可以。但 LeetCode 官方题解和很多代码风格指南里，更推荐这种先判断再前进的写法，因为循环结构更清晰，不容易漏掉空指针判断。

3. 快慢指针的核心原理——为什么一定能追上

3.1 用相对速度理解"追上"的过程

写代码容易，但如果面试官问一句"为什么快指针每次走两步一定能追上慢指针，而不是跳过它？"，很多同学就卡住了。这里的关键是理解"相对速度"。

慢指针每次走 1 步，快指针每次走 2 步，那么相对而言，在一个步进单位内，快指针比慢指针多走 1 步。也就是说，快指针在一步步地"接近"慢指针。假设某时刻快指针在慢指针后面距离 d 的位置，那么每走一步，这个距离 d 就减少 1。因为链表的节点是离散的，这个距离每次减 1，一定会减到 0，也就是快指针和慢指针正好处于同一个节点上。它不会出现"跳过"的情况，因为距离是整数步，每次减少 1，必然会经过 0 这一点。

这里有一个很自然的追问：如果快指针每次走 3 步呢？每走一步，快指针相对慢指针多走 2 步，也就是距离 d 每次减少 2。如果 d 是奇数，那么减少到 -1 时，快指针就超过了慢指针一个节点，跳过了，下次再想相遇可能就要等到下一圈了。所以步长相差 2 是最稳妥的选择。当然，快指针走 3 步也不是完全不能相遇，只是分析起来更复杂，而且在某些环结构下可能永远不相遇或需要更多圈——但既然 2 步已经是最优解，我们不需要给自己找麻烦。

3.2 证明链表有环时快慢指针必然相遇

为了把这个问题说透，我再给一个数学上的简单论证。假设链表中有环，环的长度为 L（即环上的节点数）。当慢指针刚进入环的时候，假设快指针已经在环内，并且距离慢指针还有 k 步。因为快指针相对慢指针每步前进 1，所以经过 k 步之后，快指针就会追上慢指针并相遇。而 k 不会超过 L-1，所以相遇不会等太久。

这里顺便算一下，如果链表很短，环入口在很靠前的位置，快指针已经在环内走了很多圈了，情况会复杂一些吗？不会。因为关键在于相对距离，而不是绝对圈数。只要环存在，快指针和慢指针都会在环内稳定运动，快指针最终一定能在有限步内追上慢指针。

结论就是：快慢指针相遇，就等价于链表存在环。这个结论在数学上是严格成立的，不需要额外条件。

3.3 快指针为什么必须从头节点出发

很多刚学快慢指针的同学还有一个疑问：为什么要从 head 出发，不能从环内某个节点出发吗？其实问题不是"能不能"，而是"我们事先不知道环在哪里"。我们唯一的入口就是 head，所以两个指针必须从 head 出发。慢指针总是能一步步走完链表的前半段，而快指针走得快，可能先进入环内转圈子。当慢指针到达环入口时，快指针多半已经在环内走了若干圈了。这完全不影响判断的准确性，因为相遇的本质是"追上"，而追上不要求两个指针处在"同步"的起点。

3.4 从"判断有环"到"找出入环点"的跃迁

判断有环只是第一步，面试官通常还会追问升级版问题：不仅要判断有没有环，还要找到环的入口节点。这就引出了 LeetCode 142 这道经典题，也是环形链表知识点的真正深水区。好消息是，找到入环点不需要新的算法思路，只用在快慢指针相遇后，再做一次简单的数学推导，就能定位入口。

4. 找到入环点的完整推导——Floyd 算法的数学原理

4.1 先定义变量：头节点到入环点，入环点到相遇点

我把这张图用文字画出来，大家跟着想象一下：假设链表是一个"带尾巴"的结构，头节点 head 到入环点（记为 A）之间有一段直线，长度为 a；环本身是一个圆圈，按顺时针方向，从 A 出发走一段距离可以到达相遇点（记为 B），这段距离记为 b；从 B 继续走回 A 的距离记为 c。那么环的长度 L = b + c。

为了方便说明，我再明确一下几个关键位置：

• H：头节点
• A：入环点（环的入口，也就是第一个进入环的节点）
• B：快慢指针第一次相遇的节点

H 到 A 的距离是 a；A 到 B 的距离是 b（沿着 next 方向走）；B 到 A 的距离是 c（继续沿着 next 方向走，再回到 A）；环的全长 L = b + c。

4.2 列方程：慢指针走了多少，快指针走了多少

现在把两个指针的运动过程梳理一遍。慢指针到达 A 时，走了 a 步。随后它从 A 出发，在环内继续走。假设在相遇点 B 时，慢指针总共走了 a + b 步。

那这个时候快指针总共走了多少步呢？它的速度是慢指针的 2 倍，所以时间相同的情况下，快指针走了 2 × (a + b) 步。但这里有个关键点：快指针在遇到慢指针之前，一定已经在环内转了若干圈。直观想一下——快指针先到环，可能在环内转了一圈甚至几圈，才等到慢指针进环并追上它。所以快指针的总步数还可以写成另一种形式：a + b + k × L，其中 k 是快指针进入环后再到相遇时已经绕的完整圈数，L 是环的长度。

于是我们得到一个方程：

2 × (a + b) = a + b + k × L

两边同时减去 (a + b)：

a + b = k × L

也就是说，慢指针从 H 到 B 走的总路程 a + b，正好等于环长度的整数倍。

4.3 关键结论：相遇点继续走到入环点的距离等于 a

我们从 b 和 c 的角度来理解。由于 L = b + c，所以：

a + b = k × (b + c)

把 b 移到右边：

a = k × (b + c) - b = (k - 1)(b + c) + c

化简到最后一项就是：从头节点 H 到入环点 A 的距离 a，等于从相遇点 B 继续沿着 next 方向走 c 步（回到 A），再绕 k-1 圈回到 A 的距离。换句话说，如果在一个指针放在 H，另一个指针放在 B，两个指针同时以相同的速度（每次一步）往前走，它们最终会在 A 点相遇。

这个结论是整个找入环节点的核心。它的意义在于，我们不需要知道 a、b、c 的具体数值，只需要利用快慢指针相遇后，把快指针（或者任意一个指针）重新放回 head，然后两个指针同时以步长 1 往前走——它们相遇的那个节点，就是入环点。

4.4 为什么这个推导如此优雅

我当年第一次看到这个推导的时候，最大的感受是"原来数学公式可以直接翻译成算法"。整个过程里没有用到任何高深的技巧，核心就是设变量、列方程、消元。但它解决了一个看似需要 O(n) 空间才能解决的问题——找入环点只需要两个指针，不需要哈希表，空间复杂度 O(1)。这种"通过数学推导把空间换时间"的思路，在算法题里很常见，但在链表这里体现得尤其明显。

5. 从推导到代码——找出入环点的完整实现

5.1 完整代码（LeetCode 142 解法）

来看看具体代码，我用 Java 写一个标准答案：

java复制public ListNode detectCycle(ListNode head) {
    if (head == null || head.next == null) {
        return null;
    }

    ListNode slow = head;
    ListNode fast = head;

    // 第一次循环：找到相遇点
    while (fast != null && fast.next != null) {
        slow = slow.next;
        fast = fast.next.next;
        if (slow == fast) {
            break;
        }
    }

    // 没有相遇，说明没有环
    if (fast == null || fast.next == null) {
        return null;
    }

    // 第二次循环：找到入环点
    slow = head;
    while (slow != fast) {
        slow = slow.next;
        fast = fast.next;
    }
    return slow;
}

这段代码有几个细节值得注意。首先是第一次循环的条件，必须同时判断 fast 和 fast.next 不为空，这是为了防止空指针异常。其次，循环内部一旦发现 slow == fast，立即 break 出来——此时 fast 一定不为空，因为相遇的前提是 fast 在环内正常移动。最后是第二次循环，slow 回到 head，fast 留在相遇点，两个指针都以步长 1 前进，相遇时就返回 slow。

5.2 边界条件与特殊情况

写链表题，边界条件永远是重点，也是最容易出 bug 的地方。我来梳理一下环形链表相关的几种特殊情况：

• 空链表：head 为 null，直接返回 null，没有环。
• 单节点链表：只有一个节点，next 指向 null，没有环。但如果这个节点的 next 指向自己，那就是一个长度为 1 的环，入环点就是这个节点本身，算法同样能正确处理。
• 整条链表就是一个环：head 就是入环点，a = 0。根据公式，从相遇点出发和从头节点出发同时走，必然在 head 相遇，代码逻辑自然成立。
• 两个节点的环：head 指向节点 1，节点 1 指向节点 2，节点 2 指回节点 1。快慢指针第一次循环就能相遇，第二次循环也正确处理。

为了直观验证，我手把手模拟一下"head -> 1 -> 2 -> 3 -> 2"这个例子。入环点是节点 2，环是 2 -> 3 -> 2。

第一次循环：

• 初始：slow = head（节点 1 之前），fast = head。
• 第 1 步：slow 到节点 1，fast 到节点 2。
• 第 2 步：slow 到节点 2，fast 到节点 3。
• 第 3 步：slow 到节点 3，fast 到节点 2（因为节点 3 的 next 指向节点 2）。
• 第 4 步：slow 到节点 2，fast 到节点 3。
• 第 5 步：slow 到节点 3，fast 到节点 2。

慢着，这里看起来 slow 和 fast 一直没相遇。让我重新模拟：其实快慢指针的初始位置都是 head，而 head 到节点 1... 严格来说 head 是虚拟头节点还是第一个节点？为了模拟简单，我假设 head 本身就是第一个节点，值为 1。那么链表是 1 -> 2 -> 3 -> 2，入环点是 2，环是 2 -> 3 -> 2。

• 初始：slow = 1，fast = 1。
• slow = 2，fast = 3。
• slow = 3，fast = 2（3 的 next 是 2）。
• slow = 2，fast = 2（2 的 next 是 3，3 的 next 是 2，所以 fast 从 3 走到 2）。相遇了！

好，快慢指针在节点 2 相遇。接下来第二次循环：slow 回到 head（节点 1），fast 留在相遇点（节点 2）。两个指针同时以步长 1 前进。slow 从 1 走到 2，fast 从 2 走到 3（因为 2 的 next 是 3），两者还没相遇。slow 从 2 走到 3，fast 从 3 走到 2，两者还没相遇。slow 从 3 走到 2，fast 从 2 走到 3，还没相遇... 等等，这个模拟好像出问题了？

我重新想想。按照上面推导，slow 回到 head，fast 留在相遇点，两个指针同时同速前进，相遇点就是入环点。但按照我模拟的这个例子，两者似乎一直错过了？这说明我选的相遇点和入环点的关系可能有点特殊，让我再仔细模拟一遍。

重新模拟第一步：初始 slow = 1，fast = 1（都是头节点）。

• 第 1 轮：slow = slow.next = 2；fast = fast.next.next = 3。slow != fast。
• 第 2 轮：slow = slow.next = 3；fast = fast.next.next = 2（3 的 next 是 2，2 的 next 是 3）。slow != fast。
• 第 3 轮：slow = slow.next = 2；fast = fast.next.next = 2（2 的 next 是 3，3 的 next 是 2）。slow == fast，相遇在节点 2。

所以相遇点是节点 2。然后第二次循环：slow 回到 head（节点 1），fast 留在相遇点（节点 2）。

• 第 1 轮：slow = 2；fast = 3（2 的 next 是 3）。slow != fast。
• 第 2 轮：slow = 3；fast = 2（3 的 next 是 2）。slow != fast。
• 第 3 轮：slow = 2；fast = 3。slow != fast。

这里无限循环了？这不对。哪里出了问题？

啊，我想明白了。在这个例子里，入环点是 2，环是 2 -> 3 -> 2，所以环的长度 L = 2。b 是 A（入环点 2）到 B（相遇点 2）的距离，b = 0。c 是 B 到 A 的距离，c = L - b = 2。a 是 H 到 A 的距离，a = 1（从 1 到 2 走 1 步）。方程 a = (k-1)L + c，其中 k=1，a = c = 1？但 c = 2，不匹配。

我是不是把 k 理解错了。回到方程推导：2(a+b) = a+b+kL，所以 a+b = kL。在这个例子里 a = 1，b = 0，L = 2，那么 a+b = 1，kL = 2k，k 的取值使得 1 = 2k，这不是整数！这怎么可能？问题出在哪里？

我画图仔细想想。链表结构：节点 1 -> 节点 2 -> 节点 3 -> 节点 2。这个环到底是什么？如果我们严格定义链表节点，节点 3 的 next 指向节点 2，那么从节点 1 出发：1 -> 2 -> 3 -> 2 -> 3 -> 2... 环就是 2 和 3 之间的双向循环。但这里有个关键：环的长度 L 到底是 2 还是别的？

如果环是 2 -> 3 -> 2，那么从 2 到 3 走 1 步，从 3 到 2 走 1 步，回到 2，环长度 2。A = 节点 2 是入环点。但等等——如果从头节点出发，第一次进入环，到达的节点是 2。如果从入环点 2 出发，沿着 next 走：2 -> 3 -> 2，走了 2 步回到起点。所以 L = 2，b = 0（相遇点就是入环点），c = 2（从相遇点走 2 步回到入环点）。a = 1（从头节点 1 到节点 2 走一步）。

慢指针走过的总步数：从头出发到相遇。相遇点在节点 2，但慢指针到节点 2 有两条路径——一种是第一次到达节点 2（此时还没有绕环），另一种是在环里转了一圈又回到节点 2。我模拟里慢指针在第 3 轮才到达节点 2，实际上它经过了：1 -> 2（第1轮末尾）-> 3（第2轮末尾）-> 2（第3轮末尾），总共走了 3 步。所以慢指针走的总步数 = 3。而它到入环点 A 的距离 a = 1，它随后在环内从 A 走到 B 的距离 b = ? 如果 B 也是节点 2，那么 b 可以取 0 也可以取 L=2，取决于它绕了几圈。严格来说，b 应该是慢指针从 A 出发到 B 时在环内走的最小非负距离，但如果相遇点在 A 本身，慢指针可能已经绕了一圈才回到 A，所以 b 在这个语境下的定义要小心。

但方程 a+b = kL 的成立不依赖于 b 的定义域，它是一个确定关系。我们代入：慢指针总步数 3 = a + m×L + b_min，其中 m 是环内完整圈数。这里 a = 1，L = 2，m = 1，b_min = 0，所以 1 + 2 + 0 = 3，成立。对应 k = m + 1 = 2。方程 a + b_min = kL？1 + 0 = 2×2？不成立。

我可能推导的时候变量混淆了。让我用更严谨的方式重新推导：

设链表头到入环点距离为 a（不计入环点本身），入环点 A 到第一次相遇点 B 沿 next 方向的距离为 b，B 到 A 沿 next 方向的距离为 c，环长 L = b + c。

慢指针从 head 出发到相遇点 B，总步数 = a + b。注意这里 b 是 A 到 B 的最小非负距离。但有一个特殊情况：如果慢指针在环里绕了整整一圈以上才到 B，那么"总步数 = a + b"就不成立了，因为还必须加上整圈。

实际上，慢指针从进入 A 到第一次到达 B，它最多走不到一整圈，因为 B 是第一次相遇点，慢指针还没机会绕整圈。但问题里相遇点可能等于入环点（如上面例子），此时 b = 0，慢指针第一次到达 A 就是 B 吗？不是！因为相遇发生在第 3 轮，那时慢指针已经经过了 A 一次、B（=A）第二次。所以慢指针在环内绕了一圈。

这个问题的根源在于：如果相遇点恰好是入环点，那么慢指针从 A 出发第一次回到 A 时已经是绕了一圈，此时同速的快指针可能正好也在 A。也就是说，b 的定义应该更精确：相遇点 B 可能等于 A，此时 b = 0，但慢指针在环内走了整整一圈。

为了正确推导，我采用更严格的标准推导方式：

慢指针总路程 = a + m×L + b，其中 m 是慢指针在环内完整圈数，b 是 A 到 B 沿 next 方向的距离（0 ≤ b < L）。快指针总路程 = 2×(a + m×L + b)。

另一方面，快指针从 A 点到 B 点，路径为：从 A 出发走 b 到 B，但因为快指针先进入环，它在慢指针到达 A 之前已经走了若干圈，然后慢指针到达 A 后，快指针从某个位置继续走，最终追上慢指针。快指针到达 A 的绝对时间比慢指针早，但这不是关键。关键是快慢指针从某个时刻（慢指针进入环）开始，快指针相对慢指针已经走了某些步数。

更方便的推导方式：当慢指针到达 A 时（时间 t1），慢指针总路程 = a。快指针总路程 = 2a，所以快指针已经在环内走了 2a - a = a 的距离（从 A 出发沿环的某个位置）。也就是说，此时快指针在环内距离 A 为 a mod L 的位置（沿 next 方向），或者说它领先或落后慢指针一定距离。

然后从 t1 到相遇时间 t2，慢指针走了 x 步，快指针走了 2x 步。两个指针在环内最终相遇。设 t1 时快指针在距离 A 为 p = (a mod L) 的位置（沿 next 方向），慢指针在距离 A 为 0 的位置。从 t1 到相遇，慢指针走了 b 步到达 B 点（距离 A 为 b），快指针走了 2b 步。但快指针在这段时间内可能绕了 n 圈。所以有方程：p + 2b = b + nL，即 p + b = nL。又 p = a mod L。所以 a mod L + b = nL。

这其实是一个更一般的表达式。如果 a 能整除 L，p = 0，b = 0 或 L，情况就特殊了。如果 a mod L ≠ 0，则 b = nL - (a mod L)，其中 n = ceil(a / L) 等。

无论如何，最后的关键结论依然是：从相遇点 B 出发走 c 步（c = L - b）回到 A，这条路线的长度等于从 H 出发到 A 的距离 a 加上若干个整环。具体推导为：c = L - b，而 b = (nL - a mod L) mod L。这个等式未必简洁，但在实际操作中，算法步骤"一个指针从 H 出发，一个从 B 出发，每次走一步，它们会在 A 相遇"是成立的，因为从 B 绕 c 步到 A 需要 c 步，而从 H 到 A 需要 a 步，a 与 c 的关系在模 L 意义下相等：a ≡ c (mod L)。因此两个指针最终一定在 A 相遇。

我这个例子比较特殊——a = 1，L = 2，c = 2（从 B=2 走 back 到 A=2，必须走 2 步），a ≡ c mod L 即 1 ≡ 2 mod 2，成立。所以从 H 出发走 a 步到 A，从 B 出发走 c 步到 A，但 c 比 a 大 1，不过两个指针同时走，从 H 出发的指针走 a=1 步到 A，而从 B 出发的指针走 1 步到节点 3，还到不了 A。这就不对了？算法说的是"同时出发，每次一步，相遇时就是 A"，但这里两者一个到了 A，一个到了 3，为什么不相遇？

我再看一下模拟：第二次循环，slow = 1，fast = 2。同时走一步：slow = 2，fast = 3，slow != fast。再走一步：slow = 3，fast = 2，slow != fast。再走一步：slow = 2，fast = 3，slow != fast。无限循环，看起来永远不会相遇？但根据代码逻辑，它应该最终会相遇。我代码写的是 while (slow != fast) { slow = slow.next; fast = fast.next; }，如果永远不相等，这就是死循环。但理论上这个算法是成立的，那我这个模拟到底哪里出了问题？

啊，我突然意识到我构造的链表有问题。节点 3 的 next 指向节点 2，那么从节点 3 走一步到节点 2，这是确定的。但"环的长度"到底怎么定义？如果环是 2 -> 3 -> 2，那么从 2 走一步到 3，从 3 走一步到 2，回环长度为 2。但入环点是 2，B 点也是 2。从 H（节点 1）到 A（节点 2）距离 a = 1。从 B（节点 2）走 c 步回到 A（节点 2），如果 c = L - b = 2 - 0 = 2，也就是说从 B 走 2 步回到 B（也即 A），走 1 步到 3，走 2 步回 2。所以从 H 出发走 a = 1 步到 A，从 B 出发走 c = 2 步到 A，这两者不等长。但同步走的话，1 步后一个到 A，一个到 3，此时还没相遇；但继续走下去会相遇吗？

让我重新审视这个例子。在第二次循环中，slow 从 1 出发，fast 从 2 出发，同速。假设它们都永远走，slow 的路径：1 -> 2 -> 3 -> 2 -> 3 -> 2...；fast 的路径：2 -> 3 -> 2 -> 3 -> 2...。slow 到达节点序列：1, 2, 3, 2, 3, 2...；fast 到达：2, 3, 2, 3, 2...。第 0 步：slow=1, fast=2；第 1 步：slow=2, fast=3；第 2 步：slow=3, fast=2；第 3 步：slow=2, fast=3；第 4 步：slow=3, fast=2... 确实永远错开。这说明算法在这里确实失效了？不可能，这个算法是经过验证的经典算法，我一定是选了一个不可能的相遇状态。

我明白了！问题出在第一次循环的相遇点。在这个例子中，第一次快慢指针相遇点真的是 2 吗？我再仔细模拟第一次循环。链表：1 -> 2 -> 3 -> 2。初始 slow=1, fast=1。第 1 轮：slow = 1.next = 2；fast = 1.next.next = 3。不相同。第 2 轮：slow = 2.next = 3；fast = 3.next.next = 2.next = 3（3 的 next 是 2，所以 fast 从 3 走两步：第一步到 2，第二步到 3）。不相同！这里我之前的模拟错了。第 3 轮：slow = 3.next = 2；fast = 3.next.next = 2.next = 3（fast 从 3 走两步：第一步到 2，第二步到 3）。不相同。第 4 轮：slow = 2.next = 3；fast = 3.next.next = 3。第一次相遇，相遇点是 3！不是 2。

我之前第 2 轮计算 fast 时出了错，以为 3.next.next = 2，实际上是先从 3 到 2 再到 3，fast 永远在 3 和 2 之间跳动，不会等于 2（取决于具体步数）。所以相遇点是节点 3，不是节点 2。那这就好办了。b = 从 A（节点 2）到 B（节点 3）的距离 = 1，c = 从 B 到 A 的距离 = 1（3 的 next 是 2），L = b + c = 2。a = 从 H（节点 1）到 A（节点 2）的距离 = 1。方程 a + b = kL：1 + 1 = 2 = 1×2，k=1，成立。然后第二次循环：slow 回到 1，fast 留在 3。同时走一步：slow = 2，fast = 2。相遇！入环点就是 2。

这个模拟虽然绕了很大弯路，但反而把快慢指针的相遇机制讲得更清楚了——你不需要精确计算快指针每一步走到了哪里，只需要知道一定会相遇即可。而第二次循环的相遇也验证了推导。如果不是为了写这段分析，我可能永远不会手动一步步跟踪快慢指针的路径，但这个跟踪过程确实让我对这个算法理解深了一层。

6. 哈希表 vs 快慢指针——复杂度与工程适用性对比

6.1 两种方案的完整对比

我把两种主流方案的优劣整理成表格，这样大家在面试的时候可以快速选择回答方向：

哈希表方案最容易被想到，因为它的思路和"检测重复"这个问题的直觉高度一致。快慢指针方案则需要一定的数学和抽象思维能力。这也是为什么在面试中先答哈希表、再答快慢指针，是一个比较稳妥的答题节奏——既展示了你具备最基础的解题能力，又展示了你对优化方案的掌握。

6.2 工程中的真实选择：什么时候用哈希表，什么时候用指针

可能有人会问：既然快慢指针空间复杂度更低，为什么工程里还要用哈希表？这个问题问得非常好。实际上，在真实工程场景里，哈希表方案往往更常用。原因有两个：

• 哈希表的实现更简单，不容易出错，而且对于单次检测来说，O(n) 的空间开销在现代服务器内存面前通常可以接受；
• 快慢指针方案虽然空间更省，但理解和维护成本更高，团队里不是每个人都熟悉 Floyd 算法。

但在某些特殊场景下，快慢指针的优势就无法替代了。比如检测一个"流式数据"是否出现循环，数据源只能顺序读取、不能随机访问，哈希表需要存储所有出现过的节点——如果数据量极大，空间成本就很可观。又比如在内存受限的嵌入式环境中，O(1) 空间的优势是决定性的。这类场景就非常适合快慢指针。

6.3 一个常见的理解误区：快慢指针不能改造"单向链表本身"

还有一个很多初学者会问的问题：快慢指针会不会改变链表结构？不会。快慢指针只是遍历链表，并没有修改任何节点的 next 指向。如果你在面试时提到这一点，会显得你对数据结构本身有足够的敏感度。当然，也有的题目会要求"检测并修复环"，那就需要额外操作了，但在 LeetCode 141/142 这个层面，我们只做检测和定位，不做修复。

7. 面试中的环形链表——从基础题到追问风暴

7.1 常见面试追问汇总

面试官很少只让你把代码写完就放你走。针对环形链表这道题，我总结了几类高频追问：

追问一：快指针每次走两步，为什么不是三步？

这个问题我在前面已经讲过了——关键在相对速度。快 2 步时相对速度为 1，距离每次减 1，一定能相遇；快 3 步时相对速度为 2，距离可能从奇数跳到 -1，也就是"跳过"了慢指针，这需要额外绕圈才能追上，分析复杂且在某些特殊环结构下可能无法相遇。不过面试官问这个问题的重点不是想听你背结论，而是想看你能不能快速分析相对速度的影响。

追问二：如果链表很长，快慢指针会死循环吗？

不会。有环时必然会相遇，无环时快指针会在循环条件内判断出 null 并退出。只要代码正确，不存在死循环的问题。你可以主动回答这一点，顺便展示你考虑了边界条件。

追问三：能不能在找入环点时用哈希表？

可以，而且更直观。入环点就是第一次出现重复的节点。不过面试官通常希望听到快慢指针的解法，因为那才是 O(1) 空间的解法。

追问四：怎么求环的长度？

这是环形链表的一个自然延伸。方法很简单：在快慢指针相遇后，让一个指针停留在相遇点，另一个指针每次走一步，记录走的步数，直到再次回到相遇点——走过的步数就是环的长度。这个操作的复杂度是 O(L)，L 是环的长度。

追问五：如果链表是用数组存储的（不是指针结构），怎么判断有没有环？

这种情况其实和"快慢指针"等价于数组下标跳跃。假设数组的每个元素存的是下一个元素的下标，从某个下标出发不断跳跃，如果跳回了已经访问过的下标，说明有环。这本质上是同一个问题，可以用相同的快慢指针思路解决。

7.2 完整面试回答模板

如果你正在准备面试，可以按照下面的脉络来组织答案：

先说最直观的哈希表方案："用一个 Set 记录访问过的节点，如果当前节点已经在 Set 中说明有环，否则加入 Set 继续走。"

然后话锋一转："但这个方案空间复杂度是 O(n)。如果要求 O(1) 空间，可以用快慢指针。慢指针每次走一步，快指针每次走两步。如果有环，快指针一定会追上慢指针；如果无环，快指针会先走到 null。"

接着补充找入环节点："追上的相遇点不一定是入环点。但从相遇点出发，一个指针回到头节点，另一个留在相遇点，两者同时以步长 1 前进，再次相遇的节点就是入环点。原因是...（然后在纸上画出示意图，简要推导）"

最后可以主动提边界条件："要注意空链表、单节点链表和整个链表就是一个环的情况。"这样一套下来，面试官对你在链表这一块的掌握程度通常就会比较满意了。

7.3 为什么这道题是"链表类题目的试金石"

我在前面说了环形链表在很多方面是一个"承上启下"的题目。说它承上，是因为它考察了链表遍历、指针操作和边界条件这些基本功；说它启下，是因为它引入的快慢指针思想，可以迁移到很多其他问题上——比如寻找链表的中点、寻找链表的倒数第 k 个节点、判断回文链表等等。如果你能把环形链表彻底吃透，再去学"链表中点""链表重排"这些问题会轻松很多。

具体来说，寻找链表中点的经典解法就是快慢指针——快指针每次走两步，慢指针每次走一步，快指针到终点时慢指针正好在中点。这个思路和环形链表的快慢指针如出一辙，只是判断条件从"是否相遇"变成了"快指针是否到终点"。所以学环形链表，本质上是在学一种通用的指针运动范式。

8. 实战中我踩过的坑——几个容易忽略的细节

8.1 Java/Python/C++ 语言差异带来的坑

环形链表代码本身不长，但不同语言写起来有一些细微的差异，我分别说一下。

C++ 版本需要特别注意指针判空：

cpp复制class Solution {
public:
    ListNode *detectCycle(ListNode *head) {
        if (!head || !head->next) return nullptr;
        ListNode *slow = head, *fast = head;
        while (fast && fast->next) {
            slow = slow->next;
            fast = fast->next->next;
            if (slow == fast) break;
        }
        if (!fast || !fast->next) return nullptr;
        slow = head;
        while (slow != fast) {
            slow = slow->next;
            fast = fast->next;
        }
        return slow;
    }
};

C++ 里最容易犯的错误是在循环条件中先访问了 fast->next->next，但没有检查 fast->next 是否为空。这会直接数组越界或空指针崩溃。

Python 版本相对来说空指针问题没那么明显，但要注意循环变量赋值：

python复制class Solution:
    def detectCycle(self, head: Optional[ListNode]) -> Optional[ListNode]:
        if not head or not head.next:
            return None
        slow = fast = head
        while fast and fast.next:
            slow = slow.next
            fast = fast.next.next
            if slow == fast:
                break
        if not fast or not fast.next:
            return None
        slow = head
        while slow != fast:
            slow = slow.next
            fast = fast.next
        return slow

Python 的坑在于 fast = fast.next.next 这一行，如果 fast.next 是 None，就会报 AttributeError。循环条件已经判断了 fast 和 fast.next 不为空，所以这里安全，但千万不要漏掉 fast.next 的判断。

8.2 一个真实的死循环 bug 复盘

我自己第一次写 142 题的时候，把第二次循环写成了在 slow == fast 之前先移动再判断，导致出现了意想不到的行为。复盘一下错误代码：

java复制// 错误写法
slow = head;
while (true) {
    slow = slow.next;
    fast = fast.next;
    if (slow == fast) break;
}

这段代码本身在逻辑上没有错——它也一样能找到入环点。但如果链表没有环，这个循环就永远不会退出。因为第一次循环结束后 fast 必然不为 null（相遇过），第二次循环里没有 null 判断，如果 I 误把无环的情况也放进来了，就会死循环。

另外，如果第一次循环结束时是因为快指针走到了 null（无环情况），我的代码会在返回值部分做了判断，但如果漏掉这个判断，在第二次循环中 fast.next 会抛空指针异常。这个 bug 是在实际调试中遇到的，很隐蔽，但一旦踩过就会记住：无论第二次循环看起来多么"必定相遇"，都不能省略对无环情况的兜底判断。

8.3 调试技巧：如何验证你的代码在所有边界条件下正确

我推荐一个简单粗暴的验证方法：自己构造特殊链表来测试。用 Java 写测试代码或者说构造测试链表的代码，对于 LeetCode 这类在线评测系统不需要，但在本地调试时非常有用。典型的测试用例包括：

• 空链表（头节点为 null）
• 只有一个节点且无环
• 只有一个节点且有环（节点 next 指向自己）
• 两个节点无环
• 两个节点有环（节点 2 的 next 指向节点 1）
• 很长的链表，入环点在中间位置
• 入环点就在头节点的位置（整个链表是个大环）
• 入环点在链表尾部附近

把这几类情况都测一遍，你的代码基本就可以放心提交了。

9. 环形链表的变体与延伸——不止于 LeetCode

9.1 从"检测环"到"检测环的入口"再到"环的长度"

环形链表这个主题可以自然延展出三连问：判断是否有环、找到入环点、计算环的长度。前两个我在前面已经详细讲过了。环的长度算法特别简单：在找到相遇点后，让一个指针停在相遇点，另一个指针以步长 1 继续走，同时计数，等它再次回到相遇点时，计数器就是环的长度。这里要注意，之所以从相遇点开始，是因为相遇点一定在环内，不需要额外确定入环点，省了一步。

9.2 快慢指针的通用思想还能解决什么问题

快慢指针不只是环检测工具，它还在很多链表题里大放异彩。比如：

• 寻找链表中点：快指针到尾部时慢指针正好在中点。这在链表排序（归并排序）、链表重排、回文链表判断里都有应用。
• 寻找链表倒数第 k 个节点：让快指针先走 k 步，然后快慢指针同步前进，快指针到达尾部时慢指针正好在倒数第 k 个节点。
• 链表成环入口的数学思想：不只是链表，数组、状态机、图结构中的环检测也可以用类似思路。

理解快慢指针的底层逻辑——"两个指针以不同速度运动，通过相对运动来捕捉周期性"——会让你在学习其他算法时有一种豁然开朗的感觉。

9.3 快慢指针思想在工程中的应用

虽然算法题是算法题，但快慢指针思想在工程里也实打实地有应用场景。举一个例子：在复杂系统的依赖图中，如果 A 依赖 B、B 依赖 C、C 依赖 A，就形成了一个循环依赖。在容器编排、服务调度、包管理器等系统中，这种循环依赖会导致任务永远无法完成。如何高效检测循环依赖？一种方法就是基于"引用计数 + 拓扑排序"，但也有系统用类似于快慢指针的思路做环检测，特别是对于不方便用哈希表保存全量状态的海量数据场景。

再比如，分布式系统中的时钟同步问题、消息队列中的消费偏移量检测，都有类似的模式——检测"是否会出现重复经过同一个状态"。虽然具体的工程实现要复杂得多，但核心思想和环形链表的快慢指针是一脉相承的。这也是为什么面试官喜欢考这道题——它不是孤立的知识点，而是很多更复杂问题的缩影。

10. 几个拓展练习——巩固你对环形链表的理解

10.1 练习一：返回链表环的起始位置（LeetCode 142 变形）

题目和 142 一样，但我建议大家先不要急着看题解，而是自己画图推导一遍。关键问题：如果头节点不在环外，而是就在环上，算法还成立吗？答案是成立。你已经理解了一个指针从头节点出发、另一个从相遇点出发这个方案的原理，那即使头节点就在环上，这个方案依然有效。

10.2 练习二：求环的长度，要求时间复杂度 O(n) 空间 O(1)

这个练习在前面已经给出了思路。实现时要注意计数器的起始位置：从相遇点出发，走到再回到相遇点，计数应该等于环的长度。可以尝试在快慢指针第一次相遇后直接写代码实现，验证一下自己是否真的理解了"相遇点在环内"这个前提。

10.3 练习三：把环形链表改回普通链表（修复环）

这类题目在一些公司面试中出现过：不仅要找到入环点，还要把环"断开"，让链表恢复正常。方法非常直接：既然找到了入环点 A，那么环内一定有一个节点的 next 指向 A。你只需要从 A 出发，沿着 next 一直走，直到某个节点的 next 再次等于 A，把它的 next 改为 null 即可。这个操作的时间复杂度是 O(L)，L 为环长，空间复杂度 O(1)。如果面试官问到了这个题目，你已经有了完整的解题路径。

10.4 练习四：用数组模拟链表，判断是否有环

如果你用的是数组存储节点，每个元素记录下一个节点的下标，那么判断是否有环的方法基本一样，但要注意数组下标和节点引用的区别。这也是一种很好的思维拓展——把"指针"抽象成"索引"，快慢指针照样适用。

11. 个人体会：学环形链表最该走的三步

按照惯例，最后分享一点我自己的学习体会。环形链表这道题，我见过太多人"一看就会、一写就废"，根本原因在于只看题解不亲自推导。我建议每个学习这道题的人都走完这三步：

第一步，不参考任何代码，自己画一个带环的链表图，用笔头模拟快慢指针的移动过程，直到你亲眼看到它们相遇。第二步，尝试自己推导入环点的公式，从 2(a+b) = a+b+kL 这个方程出发，一步一步推出结论。第三步，关掉所有参考资料，手写代码并跑通用例。

这三步走完，你对环形链表的理解会远超那些背了十遍代码的同学。我在实际学习过程中，把这三步重复了三遍，每一遍都有新的理解——第一遍明白了"为什么相遇"，第二遍明白了"为什么入环点可以这样找"，第三遍才真正意识到这个算法在空间复杂度上的精妙之处。

最后再分享一个小技巧：如果面试时一时半会儿推导不出入环点的数学关系，可以先给出哈希表的解法保底，再提"快慢指针有优化空间"，给自己争取时间重新推导。这道题就算只写哈希表解法，也能拿到不错的分数；写出快慢指针加推导，则是加分项。稳扎稳打，比冒进更重要。