Tina 小姐姐如果你按力扣 hot100 题单刷到“排序链表”这道题，并且开始有点懵，这不是错觉。这个题在力扣的原题编号是 148，在很多热题 100 清单里会被排到第 131 位左右。题目本身一句话就能读懂：给一个无序单链表的头节点 head，返回按升序排序后的链表。但进阶条件写得很凶，要求 O(n log n) 时间复杂度和常数级空间复杂度。刚习惯数组快排的人，看到这里会像被泼了一盆冷水：“数组排序几行搞定，链表上怎么全都不对劲了？”
实际上这道题是链表题里很经典的分水岭。它考察的不只是你会不会写归并排序，而是你知不知道归并、快排、堆排各自依赖数组的哪些特性，以及能不能把这些算法迁移到只能通过 next 指针前进的数据结构上。适合刷题想进阶的人，也适合准备算法面试、希望把“数组排序的肌肉记忆”升级成“底层数据结构思维”的人。我今年二刷的时候，发现当年背过答案的版本不少细节其实没吃透，所以这篇把推导过程和踩坑记录完整写一遍。
1. 先弄清楚：这题到底比数组排序难在哪
1.1 数组排序时默认的三件事，链表全做不到
数组排序之所以好写，是因为我们默认拥有几个能力，但这些能力在单链表上都不成立。
第一是随机访问。arr[mid] 是 O(1) 操作，不管数组多大，访问中间元素都只要一次寻址。单链表上不行，想找中间节点必须从头开始走，快慢指针要 O(n) 才能到中点，而且这个中点在每层递归里都要重新找。
第二是原地交换带来的便利。数组快排的 partition 核心是拿基准值和左右元素换位置，交换之后只需要维护两个下标。单链表交换节点需要维护前驱和后继，交换值虽然可以避免指针重连，但如果链表的 value 是对象引用或复杂结构，交换值的代价并不低，而且不通用。
第三是长度随手可得。数组有 length 属性，链表只能靠遍历统计。如果每一层递归都重新数一遍长度，排序的总复杂度会上升一个数量级，所以很多链表算法需要在入口处先算一次总长度，或者用别的方式避免重复统计。
这不是说链表比数组低级，而是说链表的优势在“插入、删除节点的代价低”，在随机访问和原地交换上天然劣势。排序算法选型，实际上就是在选哪条路更符合链表的物理特性。
1.2 出题人把两个复杂度写出来，基本就是在划范围
数组排序里常见的暴力方案在链表上会纷纷超时。
O(n^2) 的冒泡、选择、插入排序，在普通长度链表上大概率能过一部分测试用例，但 LeetCode 会设计大数据集，一旦链表长度上万，O(n^2) 的性能劣势立刻显现。这题明确要求 O(n log n)，等于直接否定了那些简单但慢的方案。
常数空间这个要求则更狠。很多人第一反应是“把链表所有节点丢进数组，调用 Arrays.sort 或 Collections.sort，再串起来”。这个方案在数组里确实是 O(n log n)，而且代码非常短，但额外空间是 O(n)，如果面试时这么答，大概率会被追问“如果链表有一亿个节点，内存怎么办”。空间复杂度这道题不仅筛选算法能力，还在筛选你是否理解“数据规模会影响方案选择”这件事。
另外要注意一个细节：力扣原题写的是“进阶：你能在 O(n log n) 时间复杂度和常数级空间复杂度下解决吗”，这里的常数空间指额外空间不能随输入规模增长。自顶向下归并排序的空间是 O(log n)，来自递归栈，严格来说不算常数空间。很多题解说“递归归并空间是 O(log n)，满足力扣要求”也能过，是因为力扣判题没有强制卡递归栈深度，但是在面试场合必须能区分清楚：递归版是快速解题版，迭代版才是能扛住追问的版本。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 快排、堆排、归并都要比一遍，别直接凭感觉二选一
2.1 快速排序在链表上的麻烦，不止是取不到随机基准值
很多人觉得快排数组能写，链表也能写。确实能写，但不是同一个味道。
数组快排的核心是 partition：基准值选定后，左右两个指针往中间移动，找到需要交换的元素就交换。链表的 next 是单方向的，想要让指针从右向左移动，就得先找到右半段的末尾，然后维护它的前驱，整个 partition 过程会变得很别扭。
链表快排通常要改成“拆分成两个子链表”的写法：拿头节点当基准，把剩下的节点逐个比较，小的挂 left，大的挂 right，然后递归排序左右两条链，最后再拼起来。这种写法能工作，但有两个硬伤：
- 如果链表原本已经有序，头节点做基准每次都只能拆出一边，递归深度退化成 O(n)，最坏时间复杂度是 O(n^2)。
- 单链表没法 O(1) 随机取基准值，想用随机化优化最坏情况，依然得付出遍历开销。
所以链表快排虽然可作为思路展示，但作为这道题的标准答案，它不如归并稳。
2.2 堆排的下标优势在链表中完全消失
基于比较的排序里，堆排序能达到 O(n log n) 且空间 O(1)，数组做堆排序是很好的选择。但堆排序依赖完全二叉树的下标映射：父节点是 (i-1)/2，左右孩子是 2*i+1 和 2*i+2。单链表想要访问第 k 个元素，必须从头走 k 步，那所有上浮下沉操作都会退化，整个算法的常数非常大。
如果强行用优先队列，先把所有节点扔进小根堆，再一个个弹出并串起来，时间复杂度确实是 O(n log n)，但空间复杂度是 O(n)。这对于“常数空间”要求就完全不达标了。
2.3 归并排序和链表天然匹配
归并排序最核心的两个操作就是“切分”和“合并”，这两个操作都不需要随机访问。
切分时只需要找中点，单链表的快慢指针可以 O(n) 完成。合并两个有序链表时，只需要比较两个头节点的值，把较小的节点接到结果链表的尾巴，然后移动对应链表的头指针。整个过程只用到了每个节点的 next 指针，没有任何随机访问需求，也没有交换元素的额外开销。
所以，在单链表上排序，归并排序天然就是最优选择之一。它唯一的“劣势”是递归深度需要额外空间，但这个劣势可以用自底向上的迭代归并弥补，后面的方案二就是干这件事的。
我经常用一句话提醒自己：数组排序看下标，链表排序看 next。归并算法从头到尾只依赖 next，它不挑剔数据结构的物理形态。
3. 方案一：自顶向下归并，最快的解题路径
3.1 快慢指针切链是核心一步，要明确 mid 停在哪个位置
自顶向下归并的思路非常直观：把链表分成左右两半，分别递归排序，再把两个有序子链表归并。难点集中在“怎么均匀地分成两半”和“在哪里切断”。
找中点当然用快慢指针。经典写法是：
java复制ListNode slow = head;
ListNode fast = head;
while (fast.next != null && fast.next.next != null) {
slow = slow.next;
fast = fast.next.next;
}
循环结束后，slow 指向链表的中间偏左节点。对于 4 -> 2 -> 1 -> 3 这样的四节点链表，slow 会停在第二个节点，也就是值为 2 的位置。如果链表只有两个节点，fast.next.next 是 null，循环不执行，slow 停在第一个节点。
这个“中间偏左”的设计是刻意的。因为排序链表要找的是“左半段的最后一个节点”，而不是“右半段的第一个节点”，这样便于执行切断操作：
java复制ListNode rightHead = slow.next;
slow.next = null;
把 slow.next 暂存为 rightHead，再把 slow.next 置空，链表就断成两条独立链。如果找中点时让 slow 停在中间偏右的位置，切断后左边会短一截，虽然通过合理调整也能工作，但对新手来说更容易出错，所以我建议用习惯性的中间偏左写法。
3.2 合并两个有序链表的指针操作，用虚拟头节点兜底
合并两条有序链表是非常高频的基础操作，这里用虚拟头节点能避免很多空判断。核心逻辑是：谁的值小，谁先接上去，然后移动对应链表的头指针。
java复制private ListNode merge(ListNode l1, ListNode l2) {
ListNode dummy = new ListNode(0);
ListNode cur = dummy;
while (l1 != null && l2 != null) {
if (l1.val <= l2.val) {
cur.next = l1;
l1 = l1.next;
} else {
cur.next = l2;
l2 = l2.next;
}
cur = cur.next;
}
cur.next = l1 != null ? l1 : l2;
return dummy.next;
}
为什么需要 dummy？因为合并结果链表的头节点可能是 l1 的头，也可能是 l2 的头，取决于哪个值更小。如果不设虚拟头，就得单独处理“第一个节点来自哪条链”的判断。dummy 节点让所有节点插入操作变得统一，最后直接返回 dummy.next 即可。
这里有个小细节：while 循环结束后，cur.next 可以直接接到剩余链表的头部。因为 l1 和 l2 本身已经有序，剩下的整条链都比已合并段大，直接挂上就完成了。
3.3 完整递归代码与复杂度分析
java复制class Solution {
public ListNode sortList(ListNode head) {
if (head == null || head.next == null) {
return head;
}
ListNode slow = head;
ListNode fast = head;
while (fast.next != null && fast.next.next != null) {
slow = slow.next;
fast = fast.next.next;
}
ListNode rightHead = slow.next;
slow.next = null;
ListNode left = sortList(head);
ListNode right = sortList(rightHead);
return merge(left, right);
}
private ListNode merge(ListNode l1, ListNode l2) {
ListNode dummy = new ListNode(0);
ListNode cur = dummy;
while (l1 != null && l2 != null) {
if (l1.val <= l2.val) {
cur.next = l1;
l1 = l1.next;
} else {
cur.next = l2;
l2 = l2.next;
}
cur = cur.next;
}
cur.next = l1 != null ? l1 : l2;
return dummy.next;
}
}
每一层递归都需要遍历整条链来切分和合并，递归一共有 log n 层，每层总工作量是 O(n)，所以时间复杂度是 O(n log n)。空间复杂度来自系统递归栈，是 O(log n)，不是严格的常数空间。
这个版本的优势是逻辑非常清晰，适合在笔试、白板编程时快速写出。如果面试官接下来问你怎么把空间降到常数级，就转方案二。
4. 方案二：自底向上归并，把空间压到真正的 O(1)
4.1 迭代分治的核心是步长倍增
自底向上归并的思路是把“递归切分”反着来做：先认为每个节点都是一个长度为 1 的有序链表，然后相邻的两个长度为 1 的链表合并成长度为 2 的有序链表；再让相邻的两个长度为 2 的链表合并成长度为 4 的有序链表；依此类推，直到整个链表只有一个有序块。
看起来还是那套归并思想，但不需要递归，也就不需要占栈空间。
我拿一个例子走一遍。假设原链表是 4 -> 2 -> 1 -> 3，总长度 4：
- subLen = 1：第一轮把
[4]和[2]合并成[2 -> 4]，把[1]和[3]合并成[1 -> 3]。整条链变成2 -> 4 -> 1 -> 3。 - subLen = 2：把前面两个节点
[2 -> 4]和后面两个节点[1 -> 3]合并，得到1 -> 2 -> 3 -> 4。
subLen 每次乘以 2，直到 subLen >= 总长度，此时整条链已经有序。
每一轮都会从链头开始，每次截取两个长度为 subLen 的块，合并，再把结果接到上一轮的输出末尾，直到本轮剩余节点不足两个 subLen。剩余节点不足时，只要还有一段长度为 1 到 subLen 的链，也要和可能为空的右段合并，保证剩余部分也能排好。
4.2 split 函数负责“截断”和“返回下一段的头”
自底向上归并里最容易被忽略的操作是：你得能从一条长链里切出步长为 subLen 的一段，并且把这段的后一个节点的 next 置成 null，然后返回下一段剩余链的头节点。这样才能保证每次 merge 都拿到两条“尾巴干净”的独立链表。
我习惯写一个 split 函数：
java复制private ListNode split(ListNode head, int step) {
if (head == null) {
return null;
}
for (int i = 1; head.next != null && i < step; i++) {
head = head.next;
}
ListNode right = head.next;
head.next = null;
return right;
}
调用 split(head1, subLen) 的效果是：从 head1 开始数 step 个节点，把第 step 个节点的 next 断开，返回后续链表的头节点。如果这段链不足 step 个节点，就让 head 走到最后一个节点再返回 null，同时把这段链的尾巴断干净。
这个函数在排序链表里是真正的点睛之处。它把“从长链中摘出指定长度的一段”这个抽象操作封装起来，代码会清晰很多。
4.3 完整迭代归并代码解析
java复制class Solution {
public ListNode sortList(ListNode head) {
if (head == null || head.next == null) {
return head;
}
ListNode p = head;
int length = 0;
while (p != null) {
length++;
p = p.next;
}
ListNode dummy = new ListNode(0, head);
ListNode pre;
ListNode cur;
for (int subLen = 1; subLen < length; subLen <<= 1) {
pre = dummy;
cur = dummy.next;
while (cur != null) {
ListNode head1 = cur;
ListNode head2 = split(head1, subLen);
cur = split(head2, subLen);
ListNode merged = merge(head1, head2);
pre.next = merged;
while (pre.next != null) {
pre = pre.next;
}
}
}
return dummy.next;
}
private ListNode split(ListNode head, int step) {
if (head == null) {
return null;
}
for (int i = 1; head.next != null && i < step; i++) {
head = head.next;
}
ListNode right = head.next;
head.next = null;
return right;
}
private ListNode merge(ListNode l1, ListNode l2) {
ListNode dummy = new ListNode(0);
ListNode cur = dummy;
while (l1 != null && l2 != null) {
if (l1.val <= l2.val) {
cur.next = l1;
l1 = l1.next;
} else {
cur.next = l2;
l2 = l2.next;
}
cur = cur.next;
}
cur.next = l1 != null ? l1 : l2;
return dummy.next;
}
}
重点看内层 while 循环的三行连续 split：
head1 = cur：当前这一轮要从 cur 开始处理。head2 = split(head1, subLen)：从 head1 中切出第一个 subLen 长度的链表，并拿到下一个待处理链表的头 head2。cur = split(head2, subLen)：从 head2 中切出第二个 subLen 长度的链表，同时把再下一段的头赋值给 cur，交给下一轮 while 继续处理。
这三行执行完，head1 和 head2 是两条已经切断、有序的短链，子链表内部长度为 subLen。merge 之后得到一条长度为两倍的新有序链。pre 接上这条新链，并移动到新链的末尾，等待下一块合并结果的接入。
这个版本的额外空间只用了几个 ListNode 引用，不随 n 增长，所以空间复杂度是 O(1)。时间复杂度依然是 O(n log n)，但每一轮的切分和合并都需要遍历当前链表，各轮总工作量加起来仍然是 O(n log n)。
5. 我实际写这个题踩过的坑，以及断链排查方法
5.1 递归版容易忘掉“切完之后把左半段尾巴置空”
我在二刷时犯过一个很低级的错误：用快慢指针找到 slow 之后，只是把 rightHead = slow.next 存下来，然后直接递归 sortList(head) 和 sortList(rightHead)，但忘记写 slow.next = null。
结果每次递归 sortList(head) 时，head 这条链其实还是完整的一条长链，快慢指针会再次切到某个位置，但右半段依然扣在左半段后面。最终程序不是栈溢出，就是排序结果完全不对。
这个坑的排查方法很直接：在 sortList 函数开头打印 head 的长度或者整条链值。如果递归层数过深之后，每次传入的 head 包含的节点数没有明显减少，几乎所有情况都是断链没做干净。
5.2 自底向上版最容易出问题的地方在 split 的边界条件
如果 split 函数里循环条件写成 for (int i = 1; i < step; i++)，而没有判断 head.next != null，当链表剩余节点不足 step 个时，head 会一直往后走直到变成 null，下一行取 head.next 就会空指针。
所以 split 里一定要加 head.next != null。有些实现喜欢先让 head 走 step 步，再判断是否走到 null，也可以，但一定要保证取值前 head 是合法节点。
我的建议是：把 split 当作“从指定节点开始向后数 k 个节点并截断”的独立函数单独调试。比如写一个简单的链表 1 -> 2 -> 3 -> 4 -> 5，调 split(head, 2)，看返回的是不是 3 开头的那条链，看 1 这条链的尾巴 2.next 是不是 null。
5.3 merge 后如果忘记把新链的最后一个节点指向 null，会留下原链残留
在自底向上归并中，每次 merge 的两个链表其实已经被 split 切断过，所以 merge 出来的链表尾巴是 null，这是正确状态。但如果自己在单独实现 merge 时，分别从两条链中取节点，最后 cur.next 接了剩余链后没有收尾动作，整条新链的尾巴可能会指向原链后面的节点，造成环。
这种环在递归版里容易被忽视，因为 merge 之后返回的是一个被切断的子链；但在迭代版中，pre 会把 merge 结果接在大链表上，环很容易被带到最终结果里。调试时可以写一个函数，用快慢指针检测链表是否有环，一旦排序后出现环，优先检查 merge 最后一步是否清理了尾指针。
5.4 边界用例要覆盖这些形态
我刷链表题吃过大亏，现在养成了习惯，任何排序链表题都先把这些边界用例跑一遍：
- 空链表：
[]，直接返回 null。 - 单节点：
[1]，递归终止条件必须覆盖head.next == null。 - 两个逆序节点：
[2, 1]，最头疼的快慢指针边界，能检验慢指针是否停在中点。 - 三个节点：
[3, 1, 2]，能检验“左段 2 个、右段 1 个”这种不完全对等切分。 - 已升序链表：
[1, 2, 3, 4, 5]，防止递归写得太复杂反而破坏原序。 - 带重复值：
[2, 1, 2, 3, 1]，merge 里的相等判断用<=还是<不会影响数值排序，但最好用<=保持算法稳定性。 - 很长且逆序的链表，比如 5000 个节点倒序排列，能测递归栈是否够用，以及排序复杂度是否真的接近 O(n log n)。
如果这些用例全部通过，这道题基本就算稳了。
6. 从排序链表延伸出的实战经验和练习建议
6.1 面试时先讲递归版还是先讲迭代版，顺序有讲究
面试官问“排序链表”时，我的建议是先用自顶向下归并把思路讲清楚。因为递归版的思路和代码都直观，面试官能快速确认你懂归并排序的核心逻辑。回答完整后，主动补一句“但这个版本的空间复杂度是 O(log n)，因为递归栈不算真正常数空间。如果要求 O(1) 空间，可以把递归改成迭代的自底向上归并，每轮从 subLen=1 开始切块合并”。这句话会显得你有深度，而且给面试官一个自然的追问切入点。
不要一上来就写迭代版。虽然迭代版更符合进阶要求，但它理解成本更高，如果代码里有一个边界错误，调整起来比递归版难得多。先用递归版建立正确性，再讨论优化，是最稳的沟通节奏。
6.2 这道题的变体换汤不换药
掌握了“链表 + 归并”的组合后，很多题目都能串起来。例如“合并 K 个升序链表”，核心就是两两 merge 的复用；再如“链表排序然后去重”或“对环形链表排序”，本质上仍然是先想办法找到切分点，再用归并按段合并。
链表的归并排序还有一个隐藏考点：稳定性。归并排序天然稳定，merge 时只要相等值优先取左边链即可。如果题目要求排序结果相同元素的相对位置不变，归并排序依然适用，这是快排做不到的。
6.3 小链表或特殊场景下，别执着于归并
我个人实际的经验是，LeetCode 这种题目必须用最优复杂度去解，但真实业务里如果遇到的链表很可能只有几十个节点，直接跑插入排序反而省事。插入排序在基本有序或长度很短的链表上常数极小，代码也更短。
有个工程界常见的优化思路：在实现归并排序时，如果递归或迭代到了某个子块长度小于阈值，就切到插入排序。Java 的 Arrays.sort 对基本类型数组也是类似策略。所以面试时如果被问“你还能怎么优化”，可以说“当子链表长度很短时改用插入排序减少递归开合”，能体现你对实际工程细节的理解。
最后说一点个人体会。排序链表这道题我前前后后写过很多遍，每一次重写都会发现不同的理解盲区。第一次我只背答案，第二次我会解释“为什么要切在慢指针位置”，第三次我能把迭代归并的循环结构与数组归并一一对应上。刷链表排序不是为了把这一题背下来，而是为了让自己以后遇到“某种排序算法适配特殊数据结构”的问题时，能冷静地从复杂度约束倒推可行的算法路线。这种能力，在这些题单里练出来之后，是能带到很多真实场景里的。