谨语1. 为什么链表递归题总让人卡壳：先弄清楚“递归到底是什么”
1.1 一个被低估的观察：链表天生就长着一张“子问题”的脸
合并两个升序链表这道题，几乎每个技术题库里都有，而且形态非常固定：给定两个已经按升序排好的链表，要求把它们合并成一条仍然升序的链表。很多人一上来就背迭代解法，背完也能写出正确代码，但一旦被追问“你理解递归版本吗”，或者题目稍作变形，比如让你合并 K 个升序链表，就会明显感觉到基础不牢。
问题的根源不在“合并”这两个字上，而在于很多人没有意识到：链表数据结构本身，就是为递归准备的。
为什么这么说？因为链表有一个数组没有的特性——一个链表去掉头节点之后，剩下的部分依然是链表，而且依然有序。这听起来像废话，但它恰恰是递归建模的关键。假设你现在处理的是 1 -> 3 -> 5 和 2 -> 4 -> 6 这两个链表，当你确定最小节点是 1 之后，剩下的问题变成了什么？
剩下的问题是：合并 3 -> 5 和 2 -> 4 -> 6 这两条升序链表，再把 1 接在结果的最前面。
你看，问题还是“合并两条升序链表”，只是规模变小了。这就是递归最看重的性质——结构自相似。数组递归往往还需要传下标、算边界，因为切掉一个元素之后剩下的部分不是一个独立完整的数组表示；而链表只要把头一摘，剩下的天然就是一条新链表，连额外参数都不用加。所以链表题里递归用得尤其频繁，不是算法设计者偏爱递归，而是链表结构自己就在往这个方向引导。
1.2 递归是“先往后走，再回头连线”的过程
不少初学者在看递归链表题时，脑子里只有一个抽象概念：“好像递归会一层一层往里走，然后从最深处往回返回结果”。这个理解方向是对的，但不够具体，具体到代码层面就容易懵。
我习惯用一个比喻来理解链表上的递归：你从山脚出发往山上爬，沿途每隔一段路就插一面旗子。这些旗子就是每一层递归调用在栈里留下的“待办事项”。当你爬到山顶（递归终点），开始往下撤，每撤到一面旗子，就做一件早就定好的事，然后继续往下撤。链表递归的“下山做事”环节，通常就是把某个 next 指针连好。
在合并链表这道题里，递归的向下阶段干的事情是“寻找下一段合并结果的头部”；而向上回溯阶段干的事情是“把当前这个更小的头节点，接到已经合并好的那一段结果上”。这句话建议刻在脑子里，它是理解整道题的总开关。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
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 理解成一个“包工头”：你向它要一段合并好的链表，它给你一个头节点，你顺着这个头就能走遍整段合并结果。递归函数永远要返回一个新头，这个“新头”会在回溯过程中被上一层使用。