芙蓉塘外有轻雷力扣第24题“两两交换链表中的节点”应该是我刷链表专题时印象很深的一道题。题目本身不算难，但很多人第一次接触时，都在指针顺序和边界条件上栽过跟头。这篇文章我用Python完整拆解一遍迭代和递归两种写法，把每一步指针变化、边界判断、常见报错都讲透，配套本地调试方法，希望能帮你真正做到代码随刷随懂。
题目出处是力扣热题100里的链表模块，也是面试中反复出现的基础题。它不涉及复杂算法，考的是对链表节点指针的掌控力。刷这道题不需要额外安装任何依赖包，本地Python环境装好就行，纯标准库足够跑通全部测试。下面直接开始。
1. 题目拆解：两两交换链表节点的核心难点
1.1 题目到底在问什么：从示例看交换逻辑
题目要求很简单：给定一个链表，两两交换其中相邻的节点，并返回交换后链表的头节点。注意，是交换节点本身，不是交换节点里的值。举例来说，输入链表 1→2→3→4，输出应该是 2→1→4→3；输入 1→2→3，输出应该是 2→1→3。
很多初学者容易犯一个理解偏差，以为只是把每两个节点的 val 互换。这个做法在这个题目上确实能通过，因为题目没有明确禁止交换值，但面试时你如果只交换值，很容易被追问“如果节点包含多个字段呢”“如果节点是带锁的共享对象呢”。链表题的核心是操作节点引用，而不是操作数据本身。所以我们要做的，是调整 next 指针的指向，让节点在链条上的位置真正发生变化。
另一个容易忽略的点是：交换后链表的头节点可能发生变化。原来 head 指向 1，交换后真正的新头是 2。如果代码里不处理这一点，返回的还是原来的 head，就会导致答案错误。这也是为什么后面的实现里必须引入哨兵节点，或者对头节点单独做一次特殊处理。
1.2 测试用例里的隐藏边界：空表、单节点、奇数长度
链表题最常见的坑全在边界条件。题目给出的示例都很友好，但隐藏的测试用例不会放过你。我归纳下来，必须覆盖四类：
- 空链表：head 为 None，不需要交换，直接返回 None。
- 单节点链表：head.next 为 None，没有第二个节点可以做交换，原样返回。
- 偶数长度链表：1→2→3→4，正常两两交换，最后 prev 指向 3，正好没有剩余节点。
- 奇数长度链表：1→2→3，前两个节点交换后，最后一个节点 3 保持不动，挂在交换后链表的末尾。
边界条件的本质是判断“当前这对节点是否存在”。所以你在写循环时，必须同时确认当前节点和后继节点都非空。很多人写 while prev.next: 然后直接访问 prev.next.next，遇到奇数长度就会报 AttributeError: 'NoneType' object has no attribute 'next'。我在4.1节会专门讲这个报错的完整排查过程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 迭代解法：三指针加哨兵节点的原地交换
2.1 为什么需要哨兵节点：没有它会怎样
先抛结论：迭代法里加一个哨兵节点 dummy，能让代码统一处理“头节点被换掉”的情况，避免为头节点写特殊分支。
为什么需要它？你自己手推一下没有哨兵的版本就能感受到。假设链表是 1→2→3→4，第一轮交换后，新头是 2，原来的 head 变量指向的 1 已经变成了第二个节点。如果你在函数最后 return head，返回的是 1，但正确答案是 2。当然，你可以单独处理：先判断 head 和 head.next 是否存在，再暂存 new_head = head.next，然后进入循环。但这样做会引入大量分支判断，一旦链表较长，代码可读性会明显下降。
哨兵节点的做法是在真正头节点前面加一个不参与业务逻辑的虚拟节点，val 随意，关键是让它的 next 指向原链表的头节点。这样无论链表怎么换，dummy.next 始终指向当前链表的真实头节点，最后返回 dummy.next 就一定是正确的。它就是你在链表中“立的一根桩”，让交换逻辑不再区分“这是不是头节点”，所有节点一视同仁地处理。这个技巧在力扣的很多链表题里都通用，比如删除倒数第N个节点、反转链表II，都会用到哨兵节点。
2.2 迭代代码与指针变换拆解
直接给出迭代实现的完整代码：
python复制class ListNode:
def __init__(self, val=0, next=None):
self.val = val
self.next = next
class Solution:
def swapPairs(self, head: ListNode) -> ListNode:
dummy = ListNode(0, head)
prev = dummy
while prev.next and prev.next.next:
node1 = prev.next
node2 = node1.next
# 第一步：prev 指向 node2
prev.next = node2
# 第二步：node1 指向 node2 后面的节点
node1.next = node2.next
# 第三步：node2 指向 node1
node2.next = node1
# 第四步：把 prev 移到 node1（下一轮的“前驱”）
prev = node1
return dummy.next
这个代码的核心是四步指针重连。很多人把顺序写错，本质是没理解每一行的作用。我按链表 1→2→3→4 来推演第一轮：
初始状态：prev 指向 dummy，node1 指向 1，node2 指向 2，node1.next 指向 2（即 node2），node2.next 指向 3。
- 第一步 prev.next = node2，把 dummy 的下一个节点改成 2。此时链条变成了 dummy→2→3→4，但 1→2 的连接还在，所以 1 还残留在链上，只是没有前驱指向它了。
- 第二步 node1.next = node2.next，把 1 的 next 指向 3。此时 1→2 的连接断开，变成 1→3，同时 2→3 的连接还在，链表暂时出现了 2→3 和 1→3 两条后向边，但没关系，后面马上修正。
- 第三步 node2.next = node1，把 2 的 next 指向 1。此时 2→1→3→4 就成型了，前两个节点已经完成交换。
- 第四步 prev = node1，把 prev 移到 1 的位置，为第二轮交换做准备。此时 prev.next 是 3，prev.next.next 是 4，条件成立，进入第二轮。
第二轮执行同样的操作后，链表变成 2→1→4→3，prev 最后落在 3 上，此时 prev.next 是 4，prev.next.next 是 None，循环退出，返回 dummy.next，也就是 2。
2.3 循环条件判断：什么时候退出才安全
循环条件 while prev.next and prev.next.next 是两个条件同时成立。我见过有人只写 while prev.next.next，然后空链表直接崩；也有人只写 while prev.next，结果奇数长度链表最后一轮把 None 的 next 拿给 node1，同样崩。
这里可以这样记：每一次循环都在消费两个节点，所以你必须保证“当前存在待交换的第一个节点”和“存在待交换的第二个节点”。第一个条件 prev.next 非空，保证还有节点可以参与交换；第二个条件 prev.next.next 非空，保证这个节点后面还有搭档。只要这两个条件同时满足，就说明至少还有一对节点可以交换。一旦剩下的是单个节点，或者已经没有节点，就不需要操作，直接退出。
另一个细节是 prev 在每次循环结束时要移动到 node1，也就是这一对节点交换后的第二个节点。为什么不是移动到 node2？因为 node2 已经是交换后的第一个节点，下一轮的“前驱”应该是这对节点后面的位置，也就是 node1 所在的位置。这个位置关系搞错，下一轮就会漏节点。
3. 递归解法：用函数调用栈省掉指针操作
3.1 递归公式和终止条件怎么定
递归解法的思路是：不要想全局，只看当前这一层要做什么，剩下的交给递归函数自己处理。
对于链表 1→2→3→4，我可以先记住 2 是新的头节点，然后把 1 的 next 指向“已经处理好的 3→4 链表”，最后让 2 的 next 指向 1，完成交换。这里的“已经处理好的 3→4 链表”，就是递归调用 swapPairs(3) 的返回值，即 4→3。
所以递归公式可以写成：
- 新头节点 = 原链表的第二个节点（head.next）。
- 原头节点（head）的 next = swapPairs(原本第二个节点之后的链表)。
- 新头节点的 next = 原头节点（head）。
终止条件有两种情况：链表为空，或者链表中只剩一个节点。这两种情况下都无交换可做，直接返回 head。这个终止条件必须写在递归最开始，否则会无限递归直到栈溢出。
3.2 递归执行流程：用1→2→3→4手工推演
递归的完整代码实现如下：
python复制class Solution:
def swapPairs(self, head: ListNode) -> ListNode:
if not head or not head.next:
return head
new_head = head.next
head.next = self.swapPairs(new_head.next)
new_head.next = head
return new_head
很多同学总觉得递归是黑魔法，其实把它展开成调用栈就一目了然。我用 1→2→3→4 推演一遍。
第一层调用 swapPairs(1)：
- new_head 记为 2。
- 执行 head.next = self.swapPairs(2.next)，也就是 swapPairs(3)，进入第二层调用。
第二层调用 swapPairs(3)：
- new_head 记为 4。
- 执行 head.next = self.swapPairs(4.next)，也就是 swapPairs(None)，进入第三层调用。
第三层调用 swapPairs(None)：
- 触发终止条件，返回 None。
回到第二层：
- head.next = None，即 3→None。
- new_head.next = head，即 4→3。
- 返回 new_head，也就是 4→3。
回到第一层：
- head.next = (4→3)，即 1→4→3。
- new_head.next = head，即 2→1→4→3。
- 返回 2→1→4→3。
整个递归展开后，从最深一层往回逐层构建链表，最终得到正确结果。这种写法代码非常简洁，不需要手动维护 prev 指针，思路也更贴近“每次只处理两个节点”的直觉。
3.3 递归的代价：栈空间与可读性权衡
递归写法的可读性我认为比迭代好，因为它把“交换两个节点”的局部逻辑封装得很干净。但它有两个代价：一是空间复杂度是 O(n)，因为每一层递归都要占用一个栈帧，链表长度 10000 时就会调用 10000 层，Python 默认递归深度大约在 1000 左右，过长的链表会直接抛 RecursionError。二是函数调用本身有开销，虽然在这道题里性能差异不大，但在生产代码或超长链表中，递归并不是一个稳妥的选择。
如果你在面试里写了递归，面试官大概率会追加一句“能不能用 O(1) 空间实现”。这时候你要能立刻切换到迭代写法。我个人的习惯是：分析阶段用递归想清楚逻辑，提交阶段用迭代保证空间和稳定性。两套解法都应该熟练掌握。
4. 高频Bug与本地调试技巧实录
4.1 我踩过的三个典型错误：返回值、丢节点、成环
先说说我自己刷这道题时真实踩过的坑。第一个坑是返回值错误。我在最初写迭代版本时，函数最后写了 return head，结果提交 1→2→3→4 这个用例时，输出还是 1→2→3→4，没有任何变化。排查半天，发现 head 在交换后已经变成第二个节点，而真正的头节点是原来的 head.next。第一轮交换后，head 指向的节点已经不在链表头部了。后来加上 dummy 节点，统一返回 dummy.next，问题立刻消失。
第二个坑是节点丢失。我有一次把指针顺序写成了 node2.next = node1，然后再 node1.next = node2.next，结果输出变成了 2→1→2→1 这种循环结构。原因很清晰：node1.next 在第一步没有保存 node2 的后续节点，等 node2.next 被改成 node1 后，原链表后续部分就找不到了。正确做法是先把 node1.next 指向 node2.next，再让 node2.next 指向 node1。核心原则是：修改任何 next 指针之前，先确认未来还需要访问的节点已经通过其他变量保存好了。
第三个坑是成环。废了很多时间在本地排查超时，最后发现代码里出现了自己指向自己的情况。比如链表只有两个节点 1→2 时，如果交换后把 2.next 指向 1，但 1.next 没有正确指向 None，那么链表就变成 2→1→2→1 的环。LeetCode 提交时会一直卡在测试用例上，最后报 Time Limit Exceeded。这种问题靠肉眼不容易看出来，最好用下面的可视化调试方法。
4.2 本地调试：构建链表与打印辅助函数
力扣的代码编辑器里可以通过打印调试，但最舒服的方式还是本地跑。我习惯在本地写两个辅助函数，一个用来把列表转成链表，一个用来把链表打印成列表，这样可以在每一步手动模拟输入输出。
python复制def list_to_linkedlist(arr):
dummy = ListNode(0)
cur = dummy
for val in arr:
cur.next = ListNode(val)
cur = cur.next
return dummy.next
def linkedlist_to_list(head):
res = []
cur = head
while cur:
res.append(cur.val)
cur = cur.next
return res
然后你就可以写这样的测试代码：
python复制s = Solution()
head = list_to_linkedlist([1, 2, 3, 4])
new_head = s.swapPairs(head)
print(linkedlist_to_list(new_head)) # 期望输出 [2, 1, 4, 3]
如果结果不对，可以在 swapPairs 的循环里临时加打印，比如每轮交换后打印 linkedlist_to_list(dummy.next)，观察链表变化是否符合预期。还有一个笨但有效的办法：把节点数量限制到 1、2、3、4、5 分别跑一遍，输出全部打印出来，边界问题基本能暴露。
另外我强烈建议用带图形界面的调试器或者在本地 IDE 里设断点，观察每行执行后 prev、node1、node2 的指向。链表问题最难的不是算法，而是“指针此刻到底指谁”。用断点一遍，比自己脑内推演快得多。
4.3 变体题与面试追问：K个一组翻转
刷完这道题，建议顺势看一眼力扣25题“K个一组翻转链表”。那道题要求每K个节点一组翻转，不足K个的不翻转。你会发现，当 K=2 时，25题的实现思路和24题惊人地相似，但复杂度高了不少。如果你能自己推导出25题的迭代解法，说明链表指针操作的基本功已经过关了。
面试时关于本题的高频追问我也列一下：
- 为什么用递归？递归的空间复杂度是多少？（答：O(n)，栈帧不能省略。）
- 不引入额外空间可以吗？（答：可以，迭代法 O(1) 空间。）
- 如果链表节点定义里多了一个随机指针，交换时需要考虑吗？（答：需要同时维护随机指针，否则会丢引用。）
- 如果链表非常长，递归会不会有问题？（答：会，可能栈溢出，应该用迭代。）
这些问题不是为了考你背答案，而是看你能不能从“会写代码”进化到“理解代码为什么这样写”。
5. 复杂度分析与优化空间
5.1 时间复杂度与空间复杂度到底怎么看
迭代法的时间复杂度是 O(n)，因为每个节点最多被访问两次：一次作为 node1，一次作为 node2，整体是线性遍历。空间复杂度是 O(1)，因为我们只用了 dummy、prev、node1、node2 这几个固定变量，不随链表长度增长。
递归法的时间复杂度同样是 O(n)，每一层处理一对节点，节点总数 n 决定调用次数。空间复杂度是 O(n)，因为在最坏情况下，递归调用会一直压栈，直到链表末尾才开始返回。也就是说，递归的代码更短，但付出的代价是额外的内存空间。这是算法面试中经典的“时间-空间权衡”模型，也是面试官最常考察的点。
这里我多说一句：LeetCode 的判题环境对 Python 递归深度有限制，默认递归深度大约 1000。如果某个测试用例链表长度超过这个数，递归写法会在跑用例时直接报错。虽然本题测试数据一般不会那么长，但养成“长链表优先迭代”的意识，对后续刷题有好处。
5.2 真正的优化：从交换到重连
有些人会在讨论区提出“能不能不修改节点，只修改值”的取巧方案。这种方案在本题能通过，但它不是节点交换，而是值交换。遇到节点同时携带其他字段，或者节点被多处引用时，值交换会引发严重副作用。
如果想在工程上做更优雅的优化，可以考虑“重连”思想：不是一步步小心翼翼地调 next，而是先把这一组的两个节点拆下来，再按目标顺序接回去。拆下来之后，你对这两个节点的操作就是完全局部的，不需要担心干扰后续节点。这个思路在处理链表反转这种更复杂的问题时尤其好用。
不过就本题而言，我认为迭代四步法已经足够清晰，刻意追求“更少代码”反而容易牺牲可读性。能写出正确、稳定、边界完善的代码，优先级永远高于写出“看起来很聪明”的代码。
6. 刷题心得：怎么把一道简单题吃透
这道题虽然标着中等难度，但实际更像一道“简单偏中”的链表操作题。它的价值不在于算法思想，而在于强迫你理解链表指针的每一步变化。我自己的经验是，链表题不能只看不写，也不能只写不想。你至少要能在白板上把这四步指针操作画出来，并且能解释每个节点在每一步之后指向哪里。
如果你刚开始刷链表，我建议按这个顺序练：先做“反转链表”，再做“两两交换链表中的节点”，再做“K个一组翻转链表”。这三道题难度递进，但核心都是指针重连。把这几道题吃透，链表类问题的基础就扎实了。
最后分享一个小技巧：遇到链表题，先在草稿纸上画出节点和箭头，明确每一步要断开哪条边、新建哪条边，再动手写代码。把图画清楚，指针顺序基本不会错，代码只是一步步把图画翻译出来而已。这比我当初直接硬写代码、反复提交调试高效太多了。