Leetcode 141 环形链表：快慢指针与哈希表两大解法详解

刷题打卡到第 10 天，今天轮到的是 Leetcode 141：环形链表。这道题在链表类的题目里属于“看着简单，但真想把它讲清楚并不容易”的典型代表。题目本身只要求判断链表里有没有环，但无论你是刚接触链表的 JavaScript 新手，还是准备面试时想刷经典题的开发者，都值得停下来仔细拆一下。它背后牵出的哈希表标记法、快慢指针（Floyd 判圈算法）、边界条件处理、以及 JavaScript 里引用比较的细节，几乎能帮你把链表基础再夯实一圈。

我一开始做这道题的时候，其实第一反应是“拿一个数组把访问过的节点存下来”，这当然能过，但后来在面试场景里被问到“能不能用 O(1) 空间解决”时，才意识到快慢指针才是这道题真正的灵魂。下面我会把两种主流解法、背后的核心原理、JavaScript 实现时容易踩的坑、以及本地测试环境怎么写，全部展开聊聊。

1. 题目回顾与思路拆解：环到底是怎么形成的

1.1 题目描述与输入模型

Leetcode 141 的描述很简短：给你一个链表的头节点 head，判断链表中是否有环。评测系统内部会用一个整数 pos 表示链表尾节点连接到链表中的位置（索引从 0 开始），如果 pos 为 -1，则表示链表中没有环。

这里有一个初学者很容易被绕进去的点：pos 并不是一个会传给你的参数。你在 Leetcode 上写函数时，形参列表里只有 head，根本没有 pos。pos 只是评测系统在构造测试数据时使用的内部标记。也就是说，你需要依赖链表的结构本身去判断，而不是幻想着“我拿到 pos，那如果 pos >= 0 就直接返回 true”。

要从结构上理解环，可以这样想：正常的单链表是一条单行道，每个节点的 next 指向下一个节点，最后一个节点的 next 指向 null；而环形链表相当于某个节点的 next 又指回了之前的某个节点，于是遍历时会陷入死循环，永远走不到 null。比如 head = [3,2,0,-4], pos = 1 这个示例，最后一个节点 -4 的 next 指向了索引为 1 的节点 2，所以当你遍历到 -4 后，会跳回 2，然后继续走，形成环路。

在 JavaScript 里，Leetcode 环境默认给你提供的链表节点构造函数一般是这样的：

javascript复制function ListNode(val) {
    this.val = val;
    this.next = null;
}

不过我建议你自己本地测试时，用更现代的类写法：

javascript复制class ListNode {
    constructor(val, next = null) {
        this.val = val;
        this.next = next;
    }
}

1.2 实现之前需要先确定的几个问题

动手写代码之前，最好先把几个基础问题理清楚，不然很容易在边界条件上翻车：

1. 返回值是什么？
   这是一个布尔判断问题，要求返回 true 或 false，而不是返回环的入口节点，也不是返回环的长度。所以代码尾部只需要 return true; 或 return false;。

2. 空链表和单节点链表算有环吗？
   如果 head 是 null，链表里根本没有节点，自然没有环。如果只有一个节点，且它的 next 为 null，也没有环。只有节点的 next 最终能指回链路中某一个节点时，才算有环。

3. 题目有没有给节点数量的范围？
   Leetcode 原题一般会说明链表中节点的数量范围是 [0, 10^4]。也就是说节点数最多有一万个，递归或者某些非常笨重的写法可能会出问题，这也是需要考虑的。

4. 不能用修改原链表的方式作弊
   有些取巧做法会把访问过的节点的 next 指向一个特殊标记节点，或者把 val 改成某个固定值。虽然能在 Leetcode 上通过，但本质上破坏了输入数据，面试时也不推荐，甚至有些判题系统会检测到这种修改并导致错误。所以我下面只讲两种正规解法。

2. 解法一：哈希表标记法，最直观的“记住我来过”

2.1 核心思想与代码实现

第一种解法非常符合人的直觉：我一边遍历链表，一边把访问过的节点都记在本子上。如果走到某一个节点时，发现这个节点已经在我的本子上出现过，那就说明链表中有环；如果一直走到 null，说明没有环。

在 JavaScript 里，最合适的工具是 Set，而不是普通数组或对象：

javascript复制var hasCycle = function(head) {
    const visited = new Set();
    let curr = head;

    while (curr) {
        if (visited.has(curr)) {
            return true;
        }
        visited.add(curr);
        curr = curr.next;
    }

    return false;
};

关键点在 visited.has(curr) 这一句。这里比较的是节点对象的引用，不是节点里的 val 值。举个例子，如果链表数据是 [1, 2, 2, 3]，里面有两个节点的 val 都是 2，它们是两个完全不同的节点对象，引用不同，所以用 Set 存的时候会存两份；如果环存在，某个节点会被第二次访问到，它的引用一定和之前存的某个引用完全一致，因此能准确判断出来。

2.2 为什么“记录历史”这个方法足够可靠

环的本质是什么？是某个节点的 next 指向了链表中更早的一个节点。这个“更早的节点”不是一个值相同的节点，而是内存中同一个对象。这就意味着，只要你把访问过的对象都存下来，一旦检测到某个节点第二次出现，就可以断定链表里有环。

你可能会问：能不能用数组来存？比如：

javascript复制const visited = [];
if (visited.includes(curr)) ...

逻辑上可行，但是 visited.includes(curr) 的时间复杂度是 O(n)，数组越长，每次查找越慢，整体最坏会退化成 O(n^2)。Set 是哈希表实现，has 和 add 的平均时间复杂度都是 O(1)。在这道题节点数量最多一万的情况下，两者的实际耗时差异可能没那么夸张，但刷题时应该从一开始就养成选择合适数据结构的习惯。

不过哈希表法有一个明显的短板：空间复杂度是 O(n)。如果真的有一个很长的链表，又确实存在环，你需要把所有访问过的节点引用都留在 Set 里，内存占用会随着链表的长度线性增长。面试时往往会被追问一句“能不能优化空间”，这才是解法二登场的时机。

注意：如果真实场景里你只是在做一个“链表循环引用检测”工具，不考虑空间限制，Set 法是很好用的，因为它写起来简单、不容易出错。但如果你是为了面试或者后续做算法优化，一定要掌握快慢指针法。

3. 解法二：快慢指针，O(1) 空间的经典判圈方案

3.1 Floyd 判圈算法的直观理解

快慢指针，也叫 Floyd 判圈算法，是判断链表有没有环的教科书级解法。它的核心思想非常容易理解：想象两个人在环形跑道上跑步，一个人跑得快，一个人跑得慢。如果跑道是直的，快的人会先跑到终点离开；如果跑道是环形的，快的人最终一定会从后面追上慢的人。

对应到链表上：

• 慢指针 slow 每次走 1 步；
• 快指针 fast 每次走 2 步；
• 如果链表无环，fast 会先到达 null，循环结束，返回 false；
• 如果链表有环，slow 和 fast 终会在环内相遇，返回 true。

代码很短：

javascript复制var hasCycle = function(head) {
    if (!head || !head.next) {
        return false;
    }

    let slow = head;
    let fast = head;

    while (fast && fast.next) {
        slow = slow.next;
        fast = fast.next.next;

        if (slow === fast) {
            return true;
        }
    }

    return false;
};

3.2 为什么快指针每次走 2 步，而不是 3 步甚至更多

很多人第一次看快慢指针时，会有一个疑问：如果快指针走 3 步、4 步，不是也能追得更快吗？

这个想法听起来合理，但数学上并不总是成立。Floyd 判圈算法里选择 slow 走 1 步、fast 走 2 步是有原因的：两者进入环之后的相对速度是 1 步/次。我们可以把追及问题看成：慢指针在环上某个位置不动，快指针以每轮 1 步的相对速度逼近它。因为相对速度是 1，快指针不会“跳过”慢指针所在的位置，而是会精确地踩到同一个节点上。

如果你让快指针每次走 3 步，慢指针每次走 1 步，那么相对速度是 2。某些环长和初始距离的组合下，快指针可能跨过慢指针所在的位置，导致这一轮没相遇，甚至按某种周期规律永远踩不到同一个点上。虽然在一些具体样例中可能最终还是能遇到，但你不能保证所有情况下都能正确判断。

所以不要随便改步长。用“慢 1 快 2”是经过验证的标准配置，既保证相对速度为 1，也能在 O(n) 的时间里跑完整个追及过程。

3.3 循环条件的边界判断，以及无环时的行为

我在第一次写这个解法时，把循环条件写成了 while (fast && fast.next)，但当时并不理解为什么要同时判断 fast 和 fast.next。后来自己想明白：

fast 每次要跳两步，即 fast.next.next。为了保证这一步合法，必须保证：

1. fast 本身不是 null；
2. fast.next 不是 null。

如果 fast 是 null，访问 fast.next 会直接抛错；如果 fast.next 是 null，访问 fast.next.next 也会抛错。尤其对于无环的奇数长度链表，快指针会恰好走到最后一个节点，它的 next 是 null，此时再跳两步就越界了。因此 while 条件要写成 fast && fast.next，而不能只写 while (fast.next)。

如果链表无环，fast 总是走在前面，它会先一步遇到 null，然后循环结束，函数返回 false。slow 甚至都还没来得及把整个链表走完，逻辑上不会有问题。

边界情况也要单独处理：如果 head 本身是 null，或者 head.next 是 null，直接返回 false。因为空链表和一个节点下面没有任何节点的链表，显然不会有环。

3.4 单节点自环的情况下为什么也能判断

有一种比较特殊的测试用例是 head = [1], pos = 0，表示这个唯一的节点的 next 指向它自己。此时 head.next === head，循环开始后：

• slow 从 head 走到 head（1 步）；
• fast 从 head 走两步，也就是 head 的 next 的 next。由于 head.next 是 head，所以 fast 走完两步之后仍然回到 head；
• slow 和 fast 都等于 head，于是 slow === fast，返回 true。

这个例子也能说明，用引用比较节点是否相同，在 JavaScript 里可以直接用 === 判断，不需要比较 val。这一点在生产环境做循环引用检测时非常重要。

4. 从“能通过”到“聊得透”：面试中的延伸问题

4.1 面试官经常追问的三个升级问题

很多面试官在候选人写出快慢指针后，并不会直接放人走，而是会顺着这道题继续问几个变体，用来测试你到底只是背了模板，还是真正理解了原理。这里有三个高频追问：

第一问：怎么找到环的入口节点？

Leetcode 142 就是这个问题的标准形式。思路也很经典：

1. 先用快慢指针找到某个相遇节点；
2. 相遇后，让其中一个指针重新指向 head；
3. 两个指针都每次走 1 步，继续前进；
4. 它们下一次相遇的节点，就是环的入口。

这个结论可以通过“入环前的距离等于相遇点继续走到环入口的距离”推导出来，但具体公式推导比较复杂，我不建议你在面试时死记硬背，而是先画图理解：从 head 到环入口的距离是 a，环入口到相遇点的距离是 b，相遇点再走到环入口的距离是 c。由于快指针走了慢指针的两倍路程，可以推出 a 等于 c。所以一个指针从 head 出发，一个指针从相遇点出发，同速走，就一定会在环入口碰头。

第二问：怎么求环的长度？

当你找到相遇点后，让一个指针停在相遇点，另一个指针每次走 1 步并计数，重新回到相遇点时走过的步数就是环的长度。实现起来很直接，相当于是绕圈走一次。

第三问：如何判断两条链表是否相交？

这个问题和环形链表不是同一个解法，但也经常会连环出现。常规做法是：先分别遍历两条链表，记录长度和末尾节点；如果末尾节点不同，说明不相交；如果末尾节点相同，让较长链表的指针先走长度差，再让两个指针同步前进，第一个相同的节点就是交点。

4.2 快慢指针思想还能用到哪些地方

快慢指针并不是只能用来处理链表环问题，它本质上是一种“双指针同向移动”的套路，在很多算法题中都有变体：

• Leetcode 287 寻找重复数：可以将数组下标和值看成一种隐式链表，然后用快慢指针找环；
• 寻找链表的中间节点：慢指针走 1 步，快指针走 2 步，快指针到末尾时，慢指针正好在中间；
• 判断循环字符串、循环数组中的周期问题：有时也能转换成快慢指针找重复状态的思路。

如果你跟着 Day 1 刷到 Day 10，应该已经能感受到：很多题其实不是孤立的知识点，双指针、哈希表、递归这些思想会反复出现。把 141 题吃透，后面再做 142、287 这类题的时候，你会觉得非常亲切。

4.3 写法细节：先移动再比较，还是先比较再移动

快慢指针循环体里，比较时机也值得注意。常见的两种写法：

javascript复制// 写法 A：先移动后比较
while (fast && fast.next) {
    slow = slow.next;
    fast = fast.next.next;
    if (slow === fast) {
        return true;
    }
}

// 写法 B：先判断再移动（需要初始化时让 slow 和 fast 错开）
if (!head || !head.next) return false;
let slow = head;
let fast = head.next;
while (slow !== fast) {
    if (!fast || !fast.next) return false;
    slow = slow.next;
    fast = fast.next.next;
}
return true;

两种写法都能正确判环，但我个人更喜欢写法 A，因为它对初学者更友好：两个指针一开始都指向 head，不会因为 fast = head.next 导致有的读者疑惑“还没开始走，为什么快指针就领先一步了”。写法 B 则省掉了第一次相遇判断，在某些语言里能少一次循环迭代，但它要求你对循环退出条件非常清楚，否则一不小心就会访问空指针。

5. JavaScript 实现的几个“坑”与本地调试建议

5.1 最常见的运行时报错：读不到 next 属性

很多人在写快慢指针时遇到的第一条报错长这样：

code复制TypeError: Cannot read properties of null (reading 'next')

原因几乎都是 while 条件没有写全。比如你写成 while (fast.next)，当 fast 已经走到最后一个节点时，fast.next 是 null；下一轮循环体里尝试访问 fast.next.next，此时 fast.next 是 null，再取 .next 就会直接报错。

所以再次强调：在快慢指针里，只要 fast 一次要跳两步，就必须在 while 条件中同时判断 fast 和 fast.next。这也是 Leetcode 141 里最容易踩的坑之一。

5.2 最容易忽略的逻辑错误：比较了节点值而不是节点引用

假设链表是一个环，但是环上所有节点的 val 都不一样时，用 slow.val === fast.val 判断也能碰巧通过；可一旦环上存在值相同的节点，这种判断就会出错。比如示例 [3,2,0,-4] 中所有值都不同，你会误以为这个方法可行，但换成 [1,1,1,1] 并构造环时，就可能闹出笑话。

正确的做法永远是比较节点本身：

javascript复制if (slow === fast) {
    return true;
}

这个 === 在 JavaScript 里比较的是两个对象的内存引用，只有当两个变量指向同一个对象时才为 true。也正是因为这个特性，哈希表解法里的 Set 存“节点”而不是存“节点的值”才有意义。

5.3 本地 Node.js 环境怎么写测试用例

Leetcode 自带的代码编辑器可以直接运行测试用例，但很多时候我们想在自己电脑上调试、打断点，那就需要本地搭一个简单的测试环境。

首先定义一个链表节点的类，并写一个可以构造“带环链表”的工具函数：

javascript复制class ListNode {
    constructor(val, next = null) {
        this.val = val;
        this.next = next;
    }
}

function createLinkedListWithCycle(arr, pos) {
    if (arr.length === 0) return null;

    const nodes = arr.map((val) => new ListNode(val));

    for (let i = 0; i < nodes.length - 1; i++) {
        nodes[i].next = nodes[i + 1];
    }

    if (pos >= 0 && pos < nodes.length) {
        nodes[nodes.length - 1].next = nodes[pos];
    }

    return nodes[0];
}

然后我一般会准备几个测试用例：

javascript复制// 用例 1：经典四节点环
const head1 = createLinkedListWithCycle([3, 2, 0, -4], 1);
console.log(hasCycle(head1)); // true

// 用例 2：两个节点自环
const head2 = createLinkedListWithCycle([1, 2], 0);
console.log(hasCycle(head2)); // true

// 用例 3：单节点无环
const head3 = createLinkedListWithCycle([1], -1);
console.log(hasCycle(head3)); // false

// 用例 4：空链表
console.log(hasCycle(null)); // false

// 用例 5：单节点自环
const head5 = createLinkedListWithCycle([1], 0);
console.log(hasCycle(head5)); // true

这样你在本地跑 node test.js，就能立刻看到五种典型情况的输出是否符合预期。特别建议把空链表和单节点自环这两种极端的用例都写上，它们能帮你验证边界处理是否到位。

5.4 刷题到第 10 天的复盘心得

写这道题的时候，我突然意识到，前几天的题基本都是“拿到题目后先想用什么数据结构”，但今天这道题真正教会我的是：哪怕同一个问题，也可以通过不同视角来重新理解。哈希表法是线性视角，一路上记录所有经过的节点；快慢指针则是动态视角，直接让两个速度不同的遍历者互相追逐。

所以如果你也处于刷题初期，我给你一个小建议：不要只追求“通过”，更要把每道题的第二解法学透，然后用自己的话写进笔记。比如我在 141 题下面只记了几句话：

判断链表是否有环。解法一用 Set 存引用，空间 O(n)；解法二用快慢指针，空间 O(1)。注意 fast 每轮走两步，while 条件必须同时判 fast 和 fast.next。单节点自环可用 head 指向自己来测试。

这短短的几行字，回过头来比网上抄下来的长题解有用得多，因为它记录了我当时最容易出错的理解点。

最后再分享一个我自己的实战小技巧：如果面试时遇到链表题，先问自己三个问题——有没有环、找不找入口、能不能用 O(1) 空间。把这三个问题想清楚，很多所谓的新题其实都是旧题的变体。141 题只是这条链表问题链的第一环，后面还有 142、287、19、876 这些经典题目等着你去挑战。