爬一手好线杆反转链表，一个听起来简单到不能再简单、却几乎每次面试都能把人卡住的经典题。很多人在看答案的时候觉得"这不就改个指针吗"，可真到了白板前，要么绕不清楚prev和curr的先后关系，要么不理解递归到底是怎么一层层把链表翻过来的。我见过不少准备了大半年面试的人，前面聊项目聊得挺好，一到手写反转链表就露馅。这篇文章就把两种主流解法掰开揉碎讲清楚：一边是迭代，一边是递归。我会把每一步指针变化、递归回溯过程、常见报错和调试经验全给你盘明白，让你不光是"背下来"，而是真正能从原理上理解为什么这么写。
这个题目适合谁看？准备面试的求职者、学数据结构但总是看了就忘的初学者，以及想系统梳理链表题型的开发者。不管你是第一次接触反转链表，还是刷过几次但老觉得有根弦没拨通，这篇都能帮你把链路理顺。
1. 为什么反转链表是绕不开的基础题，两种解法分别对应什么思维
链表这玩意儿的特点就是"物理存储不连续、逻辑上靠指针串联"。你要反转它，不能像数组那样直接下标交换，只能去改每个节点的next指向。这个动作本身非常简单，但难就难在"只给你一个头节点，你必须在有限的几个指针变量里完成整条链的方向逆转"，且不能丢失节点访问能力。
很多初学者看到反转链表第一反应是"新建一个链表，遍历原链表再头插法插入到新链表"。思路没错，但这既浪费了额外空间，也完全没体现链表操作的精髓。真正常考的两类解法，其实对应了两种不同的思维模式：
迭代解法，本质是"边遍历边改造"，用一个prev指针保存已经处理好的部分，用curr指向当前正在处理的节点，再借一个临时变量保住后续未处理的部分，每走一步就原地掰弯一个箭头。整个过程像拧螺丝，一次只处理一个节点。
递归解法，本质是"把问题缩小到不能再小"。你先别管整条链表怎么反转，先假设"从第二个节点开始的后半段已经被反转好了"，那我需要做的只是让原来的head变成新链表的尾节点，并让它指向空。至于后半段怎么反转的，我不需要关心，递归会帮我处理。这是一种典型的"分而治之、信任子过程"的思维方式。
这两种解法表面只是写法不同，背后却是"自底向上的构建"和"自顶向下的分解"两种核心编程思想。能把两道都写对的人，说明两种思维都通了，这也是为什么面试官如此偏爱这道题，它就像一面照妖镜，能快速看出候选人到底有没有真正理解指针操作和递归范式。
从面试角度看，这道题还有一个天然的"追问梯度"：先让你写迭代，再让你写递归，再问两者的空间复杂度差异，再追问能不能用两个指针完成，甚至延伸出反转前N个节点、反转区间、K个一组反转等变体。能在这一步站稳，后面变形题就顺理成章。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 迭代解法：一趟遍历之内，用三个指针完成整链翻转
迭代解法的主干代码我直接放在下面，以Python语言为例，因为Python表达指针关系时最不容易被语言杂音干扰。C++、Java的写法逻辑完全相同，只是语法不同。
python复制class ListNode:
def __init__(self, val=0, next=None):
self.val = val
self.next = next
def reverseList_iterative(head):
prev = None
curr = head
while curr is not None:
next_temp = curr.next # 先保存当前节点的下一个节点
curr.next = prev # 将当前节点的next指向前一个节点
prev = curr # prev指针前进
curr = next_temp # curr指针前进
return prev
这段代码看起来非常简洁，每一步都有明确的目的。我来拆解为什么要这样设计。
2.1 为什么必须先保存next_temp再改指针
这是整个迭代解法最核心、也最容易被忽略的一步。当你在链表上执行curr.next = prev时，如果之前没有用任何变量保存过curr原本的next，那么从这个操作生效的那一刻起，链表后半段就跟你说拜拜了。因为原链表中，从当前节点出发的唯一通路就是它的next指针，你把这个指针改了，后面的节点就再也无法被访问到。
用一个生活中的类比：你在环形山路上骑自行车，每到一个路口，需要把路标箭头转个方向，但你必须先记住下一个路口的位置，再转动箭头，不然你就彻底迷路了。next_temp就是这个"记住下一个路口"的变量。
常规写法里，next_temp的作用域只在循环体内部，每轮重新赋值。这也意味着它并不增加额外的空间复杂度，因为每轮只保存一个临时引用，循环结束就被覆盖或销毁。很多人在分析空间复杂度时纠结"用了临时变量是不是就不算O(1)了"，不是的，算法空间复杂度看的是额外申请的内存随输入规模的增长速率。一个固定的临时变量，不论链表多长，都只占一个位置，因此迭代法空间复杂度是严格的O(1)。
2.2 指针推进的顺序为什么不能换
循环末尾必须分两步走：先把prev指向curr，再把curr指向next_temp。这个顺序有强烈的逻辑依赖。如果你先把curr推进到了next_temp，那pre将彻底跟丢当前节点，因为此时已经没有一个变量指向"正被处理的那个节点"了。你可以试着调换顺序，跑一下就会发现链表断了或者漏节点。
这里我提供一个逐步推演的小技巧，你在草稿纸上画三个节点（1 -> 2 -> 3），手动模拟每一步：
- 初始：prev=None, curr=1, next_temp=2（保存2）
- 执行curr.next=prev：1.next=None，链表变成1（单独）和2 -> 3（剩余）
- 执行prev=curr：prev=1
- 执行curr=next_temp：curr=2
- 第二轮循环：next_temp=3，2.next=1，链表变成2 -> 1，剩余部分是3
- 以此类推，最后prev停在3，返回3
画一遍胜过背十遍，这个推演过程建议你自己也做一次，因为面试考的不只是结果，更多时候面试官会要求你说说"当前指针分别指向谁"。
2.3 边界条件的统一处理
迭代解法一个很舒服的点在于，边界情况几乎不需要特殊处理。空链表传入时head为None，循环直接跳过，返回prev即None，正好符合逻辑。单节点链表传入时，循环执行一轮后prev成为该节点，返回正确。这种"不需要单独写if"的特性，恰恰说明解法结构优雅，变量的初始值设置是合理的。
不过要提醒一点：虽然代码不报错，但面试时你需要主动向面试官说明"空链表和单节点我考虑了，循环体自然覆盖"。这不只是展示严谨性，更是告诉对方你理解边界条件背后的原理，而不是凑巧代码能跑。
我在教别人写这个解法时，最常看到的问题就是有人把while循环写成了while curr.next而不是while curr。这两者区别很大：用curr.next作为循环条件会导致最后一个节点落掉。你可以这样理解，当curr指向最后一个节点时，curr.next是None，循环不进，最后一步的指针反转就没有执行。而且如果链表只有单个节点，curr.next直接报空指针异常。所以循环条件永远是"当前节点不为空"，而不是"下一个节点不为空"。
3. 递归解法：先深入到底，再回溯时逐一对箭头转向
递归解法初看起来极其"魔法"——代码比迭代还短，但绕的人比迭代多得多。核心代码是：
python复制def reverseList_recursive(head):
if head is None or head.next is None:
return head
new_head = reverseList_recursive(head.next)
head.next.next = head
head.next = None
return new_head
我直接告诉初次接触的人：这段代码如果只看不动手模拟，你很难真正掌握。下面我把它拆成两个阶段来讲。
3.1 递进阶段：递归"沉底"的过程
递归函数在执行到reverseList_recursive(head.next)这行时，会暂停当前函数状态，转头去处理更短的链表。假设原链表是1 -> 2 -> 3 -> 4 -> None：
- 第一次调用reverseList_recursive(1)，进入后发现1.next是2，不是None，于是调用reverseList_recursive(2)
- 第二次调用reverseList_recursive(2)，进入后发现2.next是3，不是None，于是调用reverseList_recursive(3)
- 第三次调用reverseList_recursive(3)，进入后发现3.next是4，不是None，于是调用reverseList_recursive(4)
- 第四次调用reverseList_recursive(4)，进入后发现4.next是None，符合终止条件，直接返回4
至此"递"的过程结束，程序并没有做任何反转操作，它只是不断向最深处钻，直到找到链表最后一个节点。这一步很多人的理解误区在于以为递归边递边反转，其实真正反转发生在"归"的阶段。
3.2 回溯阶段：每一层干同一件小事
当第四次调用返回4给第三次调用时，第三次调用拿到的是节点4这个新的头节点，但没有立刻返回。它要做两行关键操作：
python复制head.next.next = head # 这一步悬空着理解
head.next = None
第三次调用的head是节点3，head.next是节点4，所以head.next.next = head翻译出来就是"4的next指向3"，即在4和3之间建立一条反向箭头。接着head.next = None是"把3原来的next置空"。两行执行完，链表局部变成了4 -> 3，而3的next已经变为None。
然后第三次调用返回4。回到第二次调用，head是节点2，head.next是节点3，此刻链表状态是4 -> 3 -> 2，执行3.next = 2，再把2.next置None。如此一层层回溯，每次都是"让我后面的节点指向我，然后我断掉原来的指向"。直到回到最早的那次调用，head是1，head.next是2，执行完这两行后整条链表完全反转：4 -> 3 -> 2 -> 1 -> None。
3.3 递归的终止条件和信任问题
很多初学者卡在"为什么head是最后一个节点时直接返回head就结束了"。因为当链表只有一个节点，它已经是一个反转后的链表，根本不需要再做任何操作。空链表也是同样的道理，返回None就好。这是递归里的"最小子问题"。
还有一个心理门槛叫"信任跳跃"。写递归的时候，你不应该试图在脑子里展开所有层级的调用，而是默认"子调用会正确返回反转后的链头"，然后思考"基于这个结果，我再补上哪些操作就能让整个问题解决"。这是递归思维的核心，也是和迭代思维最大的差异点。初学者之所以觉得递归难，就是因为总想模拟全部调用栈，结果栈一深就晕。
从空间复杂度来看，递归解法是O(n)，因为每次递归调用都会在系统栈上保存一层状态。链表越长，递归层数越深，占用的栈空间线性增长。对于长度以万计的链表，递归还可能触发系统栈溢出。所以实际生产代码中，反转链表通常用迭代，面试中则两者都要能写。
这里我给一个具体推导：反转单链表递归为什么步数是n/2？不，这里没有这个说法，反转链表的递归深度是n，因为要一路递到最后一个节点才能开始归。整个过程需要n层栈帧。如果你听到有人说什么"递归是分治所以log"之类的话，那是误记了，递归反转链表的时间复杂度是O(n)，空间复杂度也是O(n)，因为每层栈都保存了局部变量。
3.4 链表的环与Memo：递归会不会陷入死循环
这也是一个面试中经常延伸的问题：如果链表本身有环，递归解法会不会死循环？答案是会。因为终止条件只检查head.next是否为None，环上的节点next永远不为None，递归会一路递到栈溢出。迭代解法对于有环链表也只会无限循环。一般面试题默认输入无环，但你能主动提到这一点就很加分。
4. 两种解法的横向对比：时间、空间、思维与代码风格
两种解法都能在O(n)时间内完成反转，但它们的差异体现在多个维度。我整理了一个对比表，你可以在面试时用这个表来做收尾总结。
| 对比维度 | 迭代解法 | 递归解法 |
|---|---|---|
| 时间复杂度 | O(n)，遍历一次 | O(n)，遍历一次（实际是递+归各n次操作） |
| 空间复杂度 | O(1)，只用几个指针变量 | O(n)，递归调用栈占用 |
| 实现难度 | 中等，指针推进顺序易错 | 初学更难，但代码更短 |
| 边界处理 | 空链表/单节点均可自然覆盖 | 终止条件统一覆盖 |
| 可读性 | 直观，适合生产环境 | 简洁但依赖递归思维 |
| 适用场景 | 任意长度链表，生产环境首选 | 短链表、教学演示、函数式风格代码 |
| 常见陷阱 | 忘记保存next_temp导致断链 | 忘记head.next = None导致成环 |
这个表格有个细节值得展开：为什么迭代解法即使忘记保存next_temp，通常得到的不是"链表被反转到一半"，而是"程序直接死循环"？因为如果你在原链表上直接断链，curr.next被改后，curr永远无法前进到下一个节点，而prev和curr的推进依赖next_temp，如果next_temp没有正确保存，循环会卡死在当前位置。这是调试时非常重要的信号。
面试中经常会被追问"两种解法你用哪种好"，我的建议是：空题先问清楚约束条件。如果链表特别长，迭代是唯一安全的选择；如果面试官明确说可以递归，那也要把递归空间复杂度说清楚。很多时候面试官真正考察的是你有没有意识到递归的额外空间开销，有些人写完递归就结束了，回答"这两种都可以"，这话不够严谨。
我在准备面试时有个习惯，会把"反转链表"作为一个模板题，分别用迭代和递归写了至少三种语言的版本：Python一版、C++一版、Java一版。写完你会发现，不同语言的指针语法会影响你理解问题的切入点。C++里你操作的是节点指针，对"引用"和"对象本身"的区别会更敏感；Java里所有对象都是引用，思考链路的指向关系反而更接近Python；而Python的简洁语法最适合快速验证思路。如果你时间有限，至少要保证两种语言各写一遍，这对巩固知识非常有用。
5. 实操中遇到的高频问题和排查技巧
这一节是我在辅导别人刷题和自己带新人时积累的"经验清单"，都是真实遇到过的坑。
5.1 反转后链表的头节点到底是谁
这是第一大误区。很多人写迭代法时，最后返回了curr而不是prev。循环结束时curr已经指向None，返回它什么也得不到。你看代码顺序：循环的最后一步是curr = next_temp，当next_temp为None时，curr是None。真正的新头节点是prev，因为prev在每轮都会更新为刚刚处理完的节点，循环结束时prev恰好停在原链表的尾节点，也就是新链表的头节点。
有个辅助记忆法：你观察迭代过程，prev一开始是最左边的"墙"（None），然后逐一向右移动，最终停在最右边的节点，它就是反转结果的头节点。返回prev才对。
同理，递归解法里，每一层返回的都是new_head，你可以在草稿纸上标注一下：第三层返回的4，第二层拿到的还是4，第一层返回的还是4。整个递归过程，头节点永远是最初那个链表的尾节点，它从最深一层开始，一路保持自己为"新头"返回到最上层。
5.2 递归里忘记head.next = None会造成什么后果
我在调试别人的代码时发现，漏掉head.next = None的情况非常多，而且诡异的地方在于：有些情况下程序看起来能跑对，有些情况会输出环状结构。
漏掉这一行的本质是：链表反转后，原来的头节点必须作为新链表的尾节点，它的next必须是None。如果你没置空，它仍然指向原链表第二个节点，而这个节点后面已经指向前面的节点了，于是形成了一个环。打印链表时最常见的结果就是：输出几个数字之后开始循环重复，甚至有些环境直接卡死。
判断方法很简单：反转后遍历一次，如果遍历长度超过原链表长度，那必然是环。面试现场你可以在写完代码后主动说一句"原来的头节点在反转后变成了尾节点，所以要把它的next指向None，这是防止成环的关键"。这句话能直接展示你对指针操作的完全掌控。
5.3 递归处理超长链表时出现栈溢出
有个同学在实际开发场景中要用反转链表处理百万级别的数据，直接写了递归版本，一跑就栈溢出。系统默认的调用栈大小是有限的，一般几万层深度就已经很危险，百万级链表必然爆栈。这其实说明了算法的理论与实际之间有巨大的鸿沟——"算法正确"和"可以部署"是两码事。解决方式很简单：改用迭代版本，空间O(1)且永远不会因深度爆栈。
递归版本在某些编程语言中有尾递归优化机制，但链表反转的递归并不是尾递归，因为递归调用之后还有head.next.next = head这样的后续操作，所以哪怕支持TCO的语言也无法把它优化成常数栈。这个细节值得记住，因为不少人在面试时会被追问"是不是所有递归都能转成尾递归"，至少在这里是不行的，因为归的过程还要做指针操作。
5.4 调试反转链表的三个实用工具
一个特别好的调试方式是"打印法"但要有策略地打印：不要打印整个链表，而是在每轮循环开头打印当前指针状态，例如：
python复制print(f"prev={prev.val if prev else None}, curr={curr.val if curr else None}, next={next_temp.val if next_temp else None}")
这样你就能清晰地看到每一步三个指针的移动过程，所有逻辑错误都会暴露在指针状态变化中。
另一个方式是"长度校验法"：反转前后分别遍历一次链表，确认节点数相同、且每个节点的值集合一致。这样可以避免"反转完发现丢了节点"这类问题。还有一个小技巧是编写一个辅助函数：
python复制def list_to_array(head):
res = []
while head:
res.append(head.val)
head = head.next
return res
把这个函数放在本地测试里，反转前输出一次、反转后输出一次，一眼就能看到结果对不对。面试时虽然不能真把这段代码写上，但你在自己练习时无比好用。
第三个方式是在本地写简单的单元测试，至少覆盖：空链表、单节点链表、两个节点链表、三个节点链表、含重复值的链表。过度大的测试样例反而难定位问题，因为一旦出错你很难说清楚是哪个环节坏了。小样本测试能精确到哪一步。
5.5 面试追问：如何验证你的反转结果是对的
面试官在你写完代码后，经常会让你"讲讲你怎么验证"。很多候选人只会说"我跑几个测试用例"。这其实不是一个很好的回答。更好的做法是：明确说出验证的核心逻辑——反转后再反转，应该回到原链表。这是一个数学上很优美的性质，也是面试官最想听到的答案。
具体来说，对任意链表L，执行reverse(L)得到L_rev，再执行reverse(L_rev)应当得到与L完全相同的链表序列。你可以用这个性质来写本地测试：
python复制def test_reverse():
head = build_list([1,2,3,4,5])
rev1 = reverseList_iterative(head)
rev2 = reverseList_recursive(rev1)
assert list_to_array(rev2) == [1,2,3,4,5]
这相当于一个不变量检查，比单纯看"输出是什么"要深刻得多。我建议你在面试时主动说出"我会用反转再反转来验证结果"——这句话比你说出一堆测试用例更有效。
6. 从反转链表延伸开去：它到底能派上什么用场
很多初学链表的人会嘀咕"我工作中根本不会手写反转链表"。这话有一定道理，但只盯着表面代码确实会漏掉更重要的东西。
反转链表是很多复杂操作的"零件"。例如判断回文链表，先用快慢指针找到中间节点，再反转后半段，然后逐节点比较，这个流程里反转链表就是核心步骤。再比如K个一组反转链表，就是反复调用"反转一个子链表"的过程。如果你熟练掌握反转链表的指针操作，这些变体题都会顺手很多。
还有一类场景是"从尾到头打印链表"，如果你不想用递归或栈，也可以先反转链表再遍历，虽然复杂度上并不占优，但练习的价值很大。
更广义来看，链表反转练的是"在不额外分配大量内存的前提下，通过有限的指针变量完成链式结构的重组"。这种能力在后面处理二叉树（比如反转二叉树、构建父子关系）、图算法（维护访问状态）、内存池管理（空闲链表的反转与回插）中都会反复用到。我自己的体会是，链表题练得多了之后，操作指针时会有一种"胸有成竹"的感觉：你知道每一步每个变量指向哪里，知道谁会被丢失、谁会被保留、在哪个节点上需要停下来。这种感觉不是靠背代码获得的，只能靠动手画图和反复推演。
延伸到实业务中，数据库缓存淘汰算法里，双向链表的节点在LRU策略中会被移动到头部，这本质上就是一种链表节点重排操作。嵌入式系统里管理内存块的空闲链表也需要高效的节点摘除与回插。虽然这些场景不会写一个独立函数叫"反转链表"，但链表指针的思维方式是完全共通的。
所以我的建议是：不要因为"反转链表代码太简单"就轻视它。花一小时把它彻底弄透、把两种解法的每个细节都推演清楚，比你漫无目的地刷二十道中等难度的链表题要有效得多。它是一个典型的"高频考点+思维放大器"，值得你多花时间。
还有一个小技巧：在你彻底掌握了反转链表后，可以试着挑战一道经典变体——反转链表的前N个节点。这个题的关键是要记录第N+1个节点作为后继，理解它之后，组合成"反转区间"就顺理成章，K个一组再进一步也水到渠成。你在面试时如果能从"反转链表"直接讲到这些递进变体，面试官对你算法能力的整体评价会明显不一样。
坚持动手画图，不要只盯代码。每次学链表题都在纸上画出节点的前后指向变化，别急着写代码。画清楚之后，代码会自己长出来。这个习惯，我到现在都还在用。