合并两个有序链表的递归解法：从递归原理到栈空间推演

1. 为什么链表递归题总让人卡壳：先弄清楚“递归到底是什么”

1.1 一个被低估的观察：链表天生就长着一张“子问题”的脸

合并两个升序链表这道题，几乎每个技术题库里都有，而且形态非常固定：给定两个已经按升序排好的链表，要求把它们合并成一条仍然升序的链表。很多人一上来就背迭代解法，背完也能写出正确代码，但一旦被追问“你理解递归版本吗”，或者题目稍作变形，比如让你合并 K 个升序链表，就会明显感觉到基础不牢。

问题的根源不在“合并”这两个字上，而在于很多人没有意识到：链表数据结构本身，就是为递归准备的。

为什么这么说？因为链表有一个数组没有的特性——一个链表去掉头节点之后，剩下的部分依然是链表，而且依然有序。这听起来像废话，但它恰恰是递归建模的关键。假设你现在处理的是 1 -> 3 -> 5 和 2 -> 4 -> 6 这两个链表，当你确定最小节点是 1 之后，剩下的问题变成了什么？

剩下的问题是：合并 3 -> 5 和 2 -> 4 -> 6 这两条升序链表，再把 1 接在结果的最前面。

你看，问题还是“合并两条升序链表”，只是规模变小了。这就是递归最看重的性质——结构自相似。数组递归往往还需要传下标、算边界，因为切掉一个元素之后剩下的部分不是一个独立完整的数组表示；而链表只要把头一摘，剩下的天然就是一条新链表，连额外参数都不用加。所以链表题里递归用得尤其频繁，不是算法设计者偏爱递归，而是链表结构自己就在往这个方向引导。

1.2 递归是“先往后走，再回头连线”的过程

不少初学者在看递归链表题时，脑子里只有一个抽象概念：“好像递归会一层一层往里走，然后从最深处往回返回结果”。这个理解方向是对的，但不够具体，具体到代码层面就容易懵。

我习惯用一个比喻来理解链表上的递归：你从山脚出发往山上爬，沿途每隔一段路就插一面旗子。这些旗子就是每一层递归调用在栈里留下的“待办事项”。当你爬到山顶（递归终点），开始往下撤，每撤到一面旗子，就做一件早就定好的事，然后继续往下撤。链表递归的“下山做事”环节，通常就是把某个 next 指针连好。

在合并链表这道题里，递归的向下阶段干的事情是“寻找下一段合并结果的头部”；而向上回溯阶段干的事情是“把当前这个更小的头节点，接到已经合并好的那一段结果上”。这句话建议刻在脑子里，它是理解整道题的总开关。

2. 三个问题定死递归骨架：终止条件、返回值、本级操作

2.1 终止条件：谁先走到头，直接把剩下那段接回来

写任何递归函数，第一件事都是问：递归什么时候停？合并两个有序链表的终止条件非常自然：只要有一条链表走空了，就不需要再比较了，直接把另一条链表剩余的部分返回。

注意一个细节，终止条件的返回值设计很讲究。如果 l1 是空链表，就返回 l2；如果 l2 是空链表，就返回 l1。这段逻辑可以写成两块独立的判断：

python复制if not l1:
    return l2
if not l2:
    return l1

有的初学者会写成 if not l1 and not l2: return None，虽然逻辑也对，但代码会更啰嗦，而且没有利用好“空链表合并任何链表，结果就是那个链表本身”这个更一般的规律。你只要理解了终止条件里返回的是“当前可用的合并结果”，就会明白为什么不用单独判断两边都为空——当 l1 和 l2 都为空时，第一个 if not l1 就会触发，返回的 l2 本来就是 None，效果完全一样。

2.2 返回值：每一个 merge 都要回答“这里合并完的新头是谁”

这是链表递归题里最核心的问题，也是很多人写错的地方。merge_two_lists(l1, l2) 这个函数，返回值必须有一个非常明确的语义：它返回的是“把 l1 和 l2 合并之后，新链表从头节点开始的那一段”。

为什么一定要强调“从头节点开始”？因为链表不像数组，不是通过下标定位一段数据的，你想让上一层的某个节点能接到“合并好的那一段”，就必须通过头指针来引用它。上一层的代码要做的是拿到这个头节点，然后把自己指向它。

你可以把 merge_two_lists 理解成一个“包工头”：你向它要一段合并好的链表，它给你一个头节点，你顺着这个头就能走遍整段合并结果。递归函数永远要返回一个新头，这个“新头”会在回溯过程中被上一层使用。

有了这个明确语义，代码的骨架就不会飘：每一层递归在完成自己的合并任务后，都要向上一层交还一个“新头”。

2.3 本级操作：谁小谁当新头，另一条线索交给下一次递归

确定终止条件和返回值之后，递归的本级动作就很好设计了。两个链表当前的头节点分别是 l1 和 l2，到底谁应该成为合并结果的头节点？当然是值更小的那个。

假如 l1.val <= l2.val，那么 l1 就是当前这一段合并结果的头节点。现在，l1 的 next 应该指向什么？应该指向“把 l1.next 和 l2 合并后得到的新链表的头节点”。因为 l1 已经被拿走了，剩下的比较在 l1.next 和 l2 之间继续。

用代码表达就是：

python复制l1.next = merge_two_lists(l1.next, l2)
return l1

反过来，如果 l2.val < l1.val，则对称处理：

python复制l2.next = merge_two_lists(l1, l2.next)
return l2

这两个分支，加上前面的终止条件，就是完整解法。三句话：谁小谁当头；把剩下的两个子链表继续递归合并；把当前头接到递归结果前面，然后返回当前头。

2.4 代码落地：Python 参考实现与易错点

完整的递归版本代码如下：

python复制def merge_two_lists(l1, l2):
    if not l1:
        return l2
    if not l2:
        return l1

    if l1.val <= l2.val:
        l1.next = merge_two_lists(l1.next, l2)
        return l1
    else:
        l2.next = merge_two_lists(l1, l2.next)
        return l2

这个版本里最容易错的点有三个。第一，忘记把递归调用结果赋给 next，直接写 merge_two_lists(l1.next, l2)，这会导致递归虽然执行了，但链表没有真正连接起来。第二，赋值之后忘记 return l1，这会让上一层拿不到当前层合并后的头节点。第三，把终止条件写成 if not l1: return l1，方向搞反，空链表把有内容的链表弄丢了。

如果你能在十分钟内亲手写下这个版本，并且能说清楚每一行为什么存在，说明这一节你真的吃透了。

3. 完整推演一遍调用链：不要背代码，要看“栈”

3.1 推演用例选择：尽量选能触发交替大小关系的用例

很多人能看懂递归代码，但真让自己手动走一遍流程，还是会晕。我的建议是拿一组简单但具备“交替性”的数据来推演，因为如果直接选一条链表整体都比另一条小，递归过程退化成一条直线，看不出回溯连接的精髓。

这里选两条长度都为 3 的链表作为推演对象：

• l1：1 -> 3 -> 5
• l2：2 -> 4 -> 6

它们在数值上严格交替，是最适合观察递归调用栈的例子。推演前再强调一次递归函数的语义：merge_two_lists(l1, l2) 负责返回“合并这两条链表后的头节点”。

3.2 每一层调用发生了什么

用表格记录每一次调用的入参、判断结果和下一层去向：

注意，第 6 层是终止条件直接返回。也就是说，第 5 层调用会在原地收到返回值 6，然后执行自己的收尾逻辑。

3.3 从最深处往回连接：“返回头”是怎么一层层接上的

从最深处开始往回走，这个过程才是整个递归真正的“连线”阶段。第 5 层里，胜出的是 5，它调用了 merge(None, 6)，拿到返回值 6。于是它执行 5.next = 6，返回 5。此时以 5 为头的那段子链表已经是 5 -> 6。

第 4 层里，胜出的是 4，它调用了 merge(5, 6)，拿到返回值 5。于是执行 4.next = 5，返回 4。此时 4 -> 5 -> 6 已经形成。

第 3 层里，胜出的是 3，它调用了 merge(5, 4->6)，拿到返回值 4。于是执行 3.next = 4，返回 3。链表延续为 3 -> 4 -> 5 -> 6。

第 2 层里，胜出的是 2，它调用了 merge(3->5, 4->6)，拿到返回值 3。所以执行 2.next = 3，返回 2。第 1 层里胜出的是 1，它调用了 merge(3->5, 2->4->6)，拿到返回值 2，执行 1.next = 2，最后返回 1。

全部结束后，从返回的 1 节点开始遍历，得到的就是 1 -> 2 -> 3 -> 4 -> 5 -> 6。我强烈建议你照着这个流程在纸上画一遍方框和箭头，把递归的向下调用和向上连接分开看。画过一遍之后，再遇到其他链表递归题，你会觉得思路清晰很多。

3.4 常见错误现场还原与调试技巧

我在带新人时见过一个很典型的错误版本：

python复制def merge_two_lists(l1, l2):
    if not l1:
        return l2
    if not l2:
        return l1

    if l1.val <= l2.val:
        return merge_two_lists(l1.next, l2)
    else:
        return merge_two_lists(l1, l2.next)

这段代码的问题在于，它把当前胜出的节点直接丢掉了。比如第一次调用时胜出的是 1，但返回值却变成了 merge(3->5, 2->4->6) 的结果，也就是 2 开头的链表。最终结果少了 1 这个节点，而且原链表结构也被破坏。

调试这类递归问题时，如果你一时看不出错在哪，可以临时给函数增加一个深度参数，打印每次调用的入参和返回值来观察行为：

python复制def merge_two_lists(l1, l2, depth=0):
    print("  " * depth + f"call: l1={l1}, l2={l2}")
    if not l1:
        print("  " * depth + f"return {l2}")
        return l2
    if not l2:
        print("  " * depth + f"return {l1}")
        return l1
    if l1.val <= l2.val:
        result = merge_two_lists(l1.next, l2, depth + 1)
        l1.next = result
        print("  " * depth + f"return {l1}")
        return l1
    else:
        result = merge_two_lists(l1, l2.next, depth + 1)
        l2.next = result
        print("  " * depth + f"return {l2}")
        return l2

打印出来的调用栈会直观地告诉你两件事：递归走了多深，以及每一层的返回值到底是谁。观察几次之后，你会对“每层返回新头”产生肌肉记忆。

4. 合并链表的复杂度真相：时间与栈空间要分开算

4.1 时间复杂度 O(m+n) 的依据

时间复杂度分析相对简单。假设两条链表的长度分别是 m 和 n，那么每一层递归都一定会从两条链表中取走一个节点作为当前合并结果的头节点。递归的下一层所处理的节点总数，永远比当前层少一个。

最坏情况下，两个链表的所有节点都会被取走一遍。也就是说，递归调用的总次数，和节点的总个数是同量级的。因此时间复杂度是 O(m+n)。这里的 m+n 不是每次遍历两条完整链表，而是两条链表中的所有节点加起来只需要被访问一次，线性扫描即可完成合并。

这个复杂度是合并有序链表这一类问题的理论下限。因为合并的结果本身包含 m+n 个节点，而且这些节点必须按序输出，你至少要查看每个节点一次才能确定它的位置。

4.2 递归栈空间为什么最坏也到 O(m+n)

这是很多人忽略的点。迭代版本只需要几个指针变量，额外空间是 O(1)。但递归版本不同，每次调用都会在系统栈上压入一个栈帧，保存当前层的参数和返回地址。函数没有返回之前，这些栈帧不会释放。

什么时候栈最深？当两个链表的节点大小交错出现时，比如 1,3,5 和 2,4,6 这种，每一层都只确定一个节点的位置，然后继续往深处调用，直到某条链表为空。这种情况下递归层数会接近 m+n，栈空间的消耗量级就是 O(m+n)。

更精确地说，递归层数不会超过 m+n，因为每进入一层，至少有一个节点被消耗掉。由于系统栈本身有容量限制，当链表特别长时，递归版本会面临栈溢出的风险。这一点在面试里经常被追问，也是递归解法和迭代解法最重要的实际差异。

4.3 递归版本会被追问的点：能不能尾递归？会不会爆栈

有人问，合并链表的递归能不能改成尾递归，从而规避栈溢出问题？这个问题很值得聊。

自然版的递归不是尾递归，因为每层递归在等到底层返回值之后，还要继续做 l1.next = ... 和 return l1 这些操作，递归调用并不是函数的最后一步。真正意义上的尾递归要求递归调用是函数返回前的最后一个动作，这样编译器或解释器才能复用当前栈帧。

那么合并链表能不能强行尾递归？可以，但需要引入额外的“结果链表尾节点”参数，一边遍历一边把新节点接到尾部。这本质上已经非常接近迭代解法了，而且代码的可读性并不比普通递归好。所以我个人不推荐为了"尾递归"这个名头去改造这道题。真正的工程解法是：能接受递归时，用递归思维快速写出清晰版本；明确要求低空间时，直接上迭代版本。

5. 想省空间？迭代版才是标准答案

5.1 迭代版本的 dummy 节点套路

迭代版的思路非常直接：用两个指针分别指向两条链表当前待比较的节点，谁小就把谁接到结果链表的尾部，然后移动对应指针。这句描述本身不复杂，但工程实现里有一个非常重要的技巧——dummy 节点。

为什么要 dummy？因为合并结果的头节点一开始是不确定的，你当然可以先判断一次哪个链表头更小，用它初始化结果头，但这样会让代码多出一个特判分支，不够整齐。更通用的做法是创建一个不参与最终数据的哑节点，让所有节点都通过 cur.next 接在 dummy 后面，最后直接返回 dummy.next。

python复制def merge_two_lists(l1, l2):
    dummy = ListNode(0)
    cur = dummy

    while l1 and l2:
        if l1.val <= l2.val:
            cur.next = l1
            l1 = l1.next
        else:
            cur.next = l2
            l2 = l2.next
        cur = cur.next

    cur.next = l1 if l1 else l2
    return dummy.next

这里还要注意循环结束后的收尾。当 l1 和 l2 中有一条走空时，另一条可能还剩下若干节点。由于剩下的节点本身已经是有序链表，直接让 cur.next 指向剩余链表的头节点即可，不用再逐个循环拼接。

5.2 递归与迭代的选型比较

两种写法在最终结果上没有区别，但它们的侧重点完全不同。我平时给学生做对比时，习惯用下面这张表：

你不需要纠结哪一个“更好”。真正优秀的开发者通常两种都能写，并且能说清楚各自代价。递归版本像是一把锋利的刀，切起来漂亮，但用得不好容易伤手；迭代版本像一把结实的普通菜刀，没那么惊艳，但非常稳定。

5.3 面试现场怎么处理“分别写两种写法”的要求

面试官让你先写递归版本时，建议在写之前简单说一句递归函数返回值的语义，比如“我让这个函数返回合并后链表的头节点”，这样既让对方知道你没在背答案，也给自己后面写代码定下锚点。

写完递归版本后，面试官很可能追问“能不能优化空间”，这时候顺势切换到迭代版本。你不需要把刚才的递归代码删掉重写，直接在旁边新写一段即可。先写核心循环，再补 dummy 节点，最后处理循环结束后剩余的链表段。整个过程只要思路清晰，两分钟内就能完成。

如果面试官先让你写迭代版本，同样可以在写完后主动提一句：“这个版本空间是 O(1)，如果你希望看递归表达，我也可以马上写递归版本。”这体现了你的思维广度，比被动等待提问要好得多。

6. 同一个递归框架还能做哪些链表题

6.1 先从合并两个链表到合并 K 个链表

理解了合并两个有序链表之后，最常见的延伸题是合并 K 个升序链表。这道题的暴力思路是逐个合并，每合并一条链表就调用一次双链表合并。但这样会产生重复遍历，效率不稳定。

更常用的方式有两种：一种是利用优先级队列，每次从 K 个链表的头节点中选出最小节点；另一种是用分治法，把 K 条链表两两配对合并，然后再把合并结果两两配对，直到只剩一条。分治法的核心 Merge 操作，用的就是本文的递归或迭代版本。你会发现，只要基础的双链表合并真的理解了，K 路合并在思想上并不会新增多少难度，只是多了一个分治的壳。

6.2 两两交换链表节点：返回值语义一变，解法就清楚

另一个很适合用来检验递归掌握程度的题目是“两两交换链表中的相邻节点”。要求是把 1->2->3->4 变成 2->1->4->3。

如果你沿用合并链表时的返回值思维，会发现解法很像。定义递归函数 swap_pairs(head)，返回“从 head 开始完成两两交换后的新链表头”。本级要做的，就是先记住第二个节点 new_head = head.next，然后让原先的第二个节点指向“从第三个节点开始交换的结果”：new_head.next = swap_pairs(head.next.next)，再让原来的 head.next = new_head，最后返回 new_head。

这个题目再次验证了链表递归题的核心套路：递归函数负责返回子问题的新头，本级操作负责调整两个节点之间的指针方向，然后把新头交给上一层。

6.3 关于递归的迁移能力：从链表题到非链表题

链表递归题练多了，你会发现一个规律：递归解法的质量，取决于你能否把“返回值语义”定义清楚。这个能力不只对链表有用。

经典题目“递归法将一个整数 n 转换成字符串”也是一个很好的例子。比如把整数 1234 转成字符串 "1234"，递归思路是先处理 n // 10 的部分，再把最后一位数字拼上去。这里的递归函数可以定义为“把整数 n 转换成不含结尾空字符的字符串”，每层递归只处理一位数字，和链表题里每层只处理一个节点，底层逻辑惊人地一致。

很多初学者学递归时，喜欢按题目类型去收集模板，链表题背一套、数组题背一套、字符串题再背一套。但实际上递归的思维模型是相通的。你在合并链表这道题里真正该带走的，不是那几行代码，而是“把大问题切成同样结构的小问题，再定义清楚小问题的返回值”这样一套可迁移的方法。

我自己的个人经验是，遇到没见过的递归题时，先在纸上写下三行文字：终止条件是什么、递归函数返回值代表什么、本级递归要做的一次性操作是什么。这三行写清楚了，代码通常就自然浮现出来了。合并链表只是这套方法的一个经典载体，但它足够简单，简单到能让你把注意力完全放在递归结构本身，而不是被复杂的业务逻辑干扰。所以这道题很适合作为递归专题里的“练功桩”——看起来平平无奇，但每次练完都会对递归多一层手感。