各位看官，各位前端界的“搬砖大师”们，大家好！
我是你们的老朋友，一个在 React 源码的泥潭里摸爬滚打过无数遍的技术博主。今天我们不聊那些花里胡哨的 Hooks，也不聊那些新出的框架骚操作，我们要来点硬核的，来点那种能让面试官听完直呼“内行”的深度剖析。
我们要聊什么？我们要聊 React Fiber。
如果有人问你：“React 的 Fiber 架构，为什么一定要用链表而不是树状结构来实现任务的中断与恢复？” 你别光回一句“因为 React 官方这么设计的”。你要像讲相声一样，把这个技术债的来龙去脉、逻辑闭环给抖搂出来。
准备好了吗？把你们的咖啡续满，我们开始这堂关于“链表与树的决斗”的实战讲座。
第一章：浏览器里的“独裁暴君”与同步树的噩梦
在 React 16 之前，或者说在 Fiber 出现之前的很长一段时间里，React 的渲染机制那是相当“纯粹”，也相当“作死”。
那时候的 React 是基于同步树的。想象一下，你有一个巨大的 DOM 树，或者说是虚拟 DOM 树。当你需要渲染一个组件时，React 会像是一个不知疲倦的希腊雕塑家，他接到了任务：“给我雕出一座大教堂！”
这个雕塑家是怎么干的呢？他会先找到树的根节点，然后递归地往下走。render -> render -> render，一层套一层，像俄罗斯套娃一样，直到把树底下的每一个叶子节点都“看”一遍。
这看起来很美好对吧？直到这棵树变得巨大无比。
假设你的页面是一个复杂的后台管理系统，里面有几百个折叠面板，每个面板里又有表单、图表、嵌套的列表。这棵树可能就有几千甚至上万个节点。
这时候，问题来了。JavaScript 是单线程的，而浏览器的主线程也是单线程的。 这俩哥们儿是住在一个屋檐下的室友，谁都不能占用电脑太久。
当年的 React 是个“卷王”，它一旦开始渲染，就发誓要把整个树看完，一个节点都不能落下。它就像一个正在跑马拉松的选手，不管前面是平路还是悬崖，它都得一口气跑完。
如果这棵树只有 10 个节点，React 闭着眼都能跑完，用户根本感觉不到卡顿，因为 5ms 的 CPU 时间完全够用。但如果这棵树有 5000 个节点呢？React 跑了 20ms，还没跑到一半，浏览器就喊停了：“哥们儿，你的代码占用了主线程太久，我要让页面卡顿一下，去渲染一下你的旧状态，或者让用户点击一下按钮！”
React 只能停下来，抱着它那棵巨大的树，擦擦汗说：“行，我歇会儿。” 然后它得把这棵树的渲染状态全部保存下来。等浏览器腾出空来，它又得重新把刚才那个断点接着往后跑。
这在技术术语上，叫“全量同步渲染”。这就像是你想一口气读完一本 2000 页的百科全书，中间肚子饿了，放下书睡觉。等醒了再接着读，你还得先回忆刚才看到哪一页，还得重新翻到那一页。这种“无记忆”的遍历方式，在树状结构中简直是灾难。
所以，树状结构最大的问题在于：它很难在不从头遍历整个树的情况下，从中间切入，或者从中间抽离任务。 树是一张层级分明的地图，而中断点往往是随机的，回到中断点需要昂贵的回溯成本。
第二章：Fiber 的诞生——把树“拆”成链表
为了解决这个问题，React 团队决定不再做一个“卷王”，他们要做一个“聪明的工头”。
他们提出了 Fiber 架构。Fiber 本意是“纤度”，在 React 里面，它指的是一种新的数据结构。这个数据结构，就是把那棵庞大的、扁平的树，变成了一条条有序的、细小的、有记忆的链表。
你想想，为什么我们平时开发数据结构用链表？因为链表插入、删除、跳转节点太方便了，对吧？
在 Fiber 之前，React 的数据流是 树 -> 树 -> 树。
在 Fiber 之后，React 的数据流变成了 链表 -> 链表 -> 链表。
每一个 React 组件实例，在渲染过程中，都会变成一个 Fiber 节点。这些节点通过指针连在一起。这个转变，是 React 16 重生之路的关键。
那么，这些 Fiber 节点是怎么连的？请看核心代码结构（简化版）：
class FiberNode {
constructor(tag, pendingProps, returnFiber) {
this.tag = tag; // 标识这是 FunctionComponent, ClassComponent 还是 HostComponent
this.pendingProps = pendingProps;
// 下面是链表的核心指针，三剑客
this.return = returnFiber; // 父节点（指路回家）
this.child = null; // 第一个子节点（往下走的路）
this.sibling = null; // 下一个兄弟节点（左边走完走右边）
// ...
}
}看到了吗？这就是所谓的 “三剑客”。它们分别代表了三种操作：
- 往深走：
this.child - 往旁边走：
this.sibling - 回老家：
this.return
这和树状结构有什么本质区别？
- 树状结构：你要找下一个节点，必须知道父节点是谁，然后去父节点的 children 数组里找。如果要找兄弟节点，还得知道父节点，去父节点的数组里找。这就像是在迷宫里，你不知道出口在哪，只能一层层爬。
- Fiber 链表结构：每个节点都知道自己的下一步去哪，也知道自己的退路在哪。这就像是一条笔直的接力棒跑道，运动员只需要关注当前这一棒。
第三章：为什么链表才能实现“打断与恢复”？
好，我们终于到了正题。为什么 Fiber 必须是链表结构？因为只有链表，才能优雅地处理任务的中断与恢复。
这是 React 源码中最迷人的逻辑之一。
1. 时间切片的核心：工作单元
Fiber 的核心思想是 “时间切片”。React 不再一口气干完所有的活，它把每一份活都切得很碎，切到 5ms 一个单位。
React 会像这样工作：
- 把“当前正在处理”的节点叫作
workInProgress。 - 开始处理
workInProgress，渲染组件，生成 DOM。 - 计时器开始。
- 如果在 5ms 内没干完，React 停止工作，把
workInProgress这个节点挂起来。 - 把
workInProgress的nextUnitOfWork（下一个工作单元）指向它的child或者sibling。 - 把
nextUnitOfWork保存起来。 - 交出主线程控制权，让浏览器去渲染刚才那 5ms 的成果。
- 下一帧：浏览器干完了自己的活，说：“React，该你了。” React 拿起保存的
nextUnitOfWork，从刚才打断的地方继续往下干。
如果是树状结构，这步操作简直就是噩梦！
假设你在处理树的第 500 层的一个叶子节点，你停下来了。你要把第 501 层之后的任务保存起来。但树结构是层级嵌套的，你怎么保存？你要把从第 500 层往下的所有子树都序列化保存到磁盘吗？太慢了！
但在链表结构中，这简直太简单了！
当你在处理节点 A（Fiber 节点）时，你的工作流程是线性的：
Node A -> Node B -> Node C -> Node D…
当你觉得累了，你只需要做两件事：
- 暂停：停止处理
Node A（或者Node B）。 - 恢复：只要把
Node B拿出来，让 React 的调度器知道：“嘿，下一个工作给我做这个 Node B 就行了。”
你不需要保存整个树的结构，你只需要保存一个指针——指向链表中下一个要执行节点的那个指针。这就是链表结构带来的巨大的空间效率和时间效率。
2. 优先级的疯狂插入：高优任务的插队
这可能是 React 18 引入的“并发模式”中最炸裂的功能。你有没有试过，在 React 正在渲染一个低优先级的列表时，突然发起了输入事件？
比如，你正在渲染一个包含 1000 条数据的表格，渲染大概需要 100ms。这时候，用户点击了输入框，输入了一个字符。这是一个高优先级任务。
如果 React 是基于树的同步渲染，那你就完了。你必须等它把这 1000 条数据全部渲染完，甚至等浏览器把这帧画完，你才能把高优先级的输入事件处理掉。这就导致了输入延迟，体验极差。
但在 Fiber 链表架构下，这一切变得可行。
React 的任务队列是一个优先级队列（堆）。当高优先级任务（比如输入事件）到来时，React 的调度器会把它插入到任务队列的顶部。
更绝的是，Fiber 节点的链表结构允许 React “重排”。
你想想，如果这棵树是静态的 DOM 树，你怎么把一个高优先级的组件提到最前面去渲染？你得遍历全树，重建整个树的结构，这成本太高了。
但是，如果是 Fiber 链表 呢？React 可以把代表这个高优先级组件的 Fiber 节点，从原来的位置“拔”出来，放到链表的头部去。
为什么能“拔”出来？因为链表没有固定的父子层级束缚，或者说，它拥有 return 指针。React 可以只改变节点的连接方式，而不需要重绘整个组件树。
代码大概是这样的逻辑（伪代码）：
// 假设当前正在处理链表中的某个节点 currentFiber
function scheduleHighPriorityWork(highPriorityFiber) {
// 1. 找到 highPriorityFiber 在当前链表中的位置（如果它不是当前正在处理的节点）
// 2. 把它从兄弟节点链中“抽离”出来
detachNode(highPriorityFiber);
// 3. 找到 React 任务队列的头部（或者利用时间片调度器）
// 4. 把它挂到头部去
insertNodeToHead(highPriorityFiber);
// 5. 此时，React 的调度器会看到这个新节点，在下一个时间片优先处理它！
// 6. 处理完这个高优任务后，它再回过头去处理刚才中断的低优任务。
}在这个过程中，链表结构保证了我们可以在不破坏整个组件树结构的前提下，实现任务的动态调度。这就像你在读一本小说，读着读着，有人告诉你：“刚才那个情节不对，插播一个紧急的高能预告！”你把预告插进去，读完了预告，再回到刚才的位置接着读。
如果是树，你想把一个节点插到最前面，你得把整棵树劈开，重新嫁接，太乱了。
第四章：代码实战——递归 vs 迭代
为了彻底讲清楚，我们来对比一下代码。
场景 A：树状结构的递归渲染（旧版 React）
// 这是一段伪代码，模拟旧版 React 的同步递归
function renderTreeOld(node) {
// 步骤1：渲染当前节点
commitNode(node);
// 步骤2：递归处理子节点
// 注意：这里是一步到位的！如果不小心栈溢出或者卡顿，前面所有的工作都白费了
if (node.children && node.children.length > 0) {
for (let i = 0; i < node.children.length; i++) {
renderTreeOld(node.children[i]);
}
}
// 步骤3：渲染兄弟节点（其实上面的循环已经处理了，只是为了逻辑清晰）
}
// 调用
renderTreeOld(rootNode);缺陷分析：这段代码没有任何“暂停”的机制。一旦进入 renderTreeOld，JS 引擎的调用栈会一路向下，直到最深处。期间任何用户操作都会被阻塞。如果要中断，你必须手动实现一个状态变量来控制递归是否继续，这在深层递归中极其难维护。
场景 B：Fiber 链表结构的迭代渲染（新版 React）
// 这段代码模拟了 Fiber 的工作单元循环（简化版）
let nextUnitOfWork = rootFiber; // 初始化工作单元为根节点
// 我们在 requestIdleCallback 或者其他调度器中循环调用这个函数
function workLoop(deadline) {
// 只要还有活要干，且时间还没用完
while (nextUnitOfWork !== null && !shouldYield(deadline)) {
// 1. 处理当前节点
nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
// performUnitOfWork 内部会决定：
// 如果有 child，nextUnitOfWork = child
// 如果没有 child 但有 sibling，nextUnitOfWork = sibling
// 如果都没有，nextUnitOfWork = return (回溯父节点)
}
if (nextUnitOfWork !== null) {
// 还有活，但是时间用完了，告诉浏览器：我休息一会儿，下次你再来叫我
requestIdleCallback(workLoop);
} else {
// 活干完了，渲染完成
commitRoot();
}
}
// 执行工作单元的函数
function performUnitOfWork(fiberNode) {
// ... 处理 effectTag, diff 算法, 构建 DOM ...
// 关键点：决定下一个去哪
if (fiberNode.child) {
// 如果有孩子，优先处理孩子（深度优先遍历）
return fiberNode.child;
}
if (fiberNode.sibling) {
// 孩子处理完了，处理兄弟节点
return fiberNode.sibling;
}
// 如果孩子和兄弟都没有，说明这是这一层级最末尾的节点了，回溯
return fiberNode.return;
}优势分析：
看这段代码，是不是很爽？它就是一个死循环（while），但是我们在循环体里手动控制了流程。
- 可控性：我们可以在
while循环里面随时return，或者通过requestIdleCallback退出循环。 - 记忆性：我们不需要把整个树存下来，只需要一个
nextUnitOfWork变量。这个变量就像一根针，串起了任务的链子。 - 灵活性：你可以随时改变
nextUnitOfWork的指向。比如刚才说的插入高优任务，你只需要把nextUnitOfWork指向那个高优节点，下一次循环它就会先被处理。
第五章：为什么“return”指针是链表的灵魂？
很多初学者看到 Fiber 结构，会问：“为什么要用链表？直接用树不行吗？DOM 不本来就是树吗？”
这里有一个非常深刻的误解。React 的 Fiber 树是为了调度而存在的，它不是给浏览器看的 DOM 树（那棵树是物理存在的），而是 React 内部用来计算“怎么干活”的逻辑树。
在这个逻辑树里，为什么要用 return 指针？
因为 Fiber 需要回溯。
在深度优先遍历（DFS）中，当你处理完所有的子节点，回到父节点时，你通常会去处理兄弟节点。当处理完所有兄弟节点，回到祖父节点，再去处理祖父的兄弟节点……
如果用数组索引模拟链表，你会很痛苦。你需要在数组里来回跳跃。而有了 return 指针，回溯就像是按返回键一样自然。
想象一下你正在一条直线传送带上干活。
- 你拿起了最上面的盒子（当前节点）。
- 传送带送下来一个更小的盒子（
child），你把它放手里，继续走。 - 你发现手里有 3 个小盒子，处理完第一个，拿起第二个，再处理。
- 3 个小盒子都处理完了，你把手里的东西放下，回到传送带的原点。
- 传送带送来一个新的大盒子（
sibling）。
在这个过程中，如果你把手里的小盒子放下了，你想知道你刚才从哪来的，你只需要看传送带（return 指针）指向哪里。
这种结构完美支持了 React 复杂的算法：
- Diff 算法：React 通过对比
oldFiber和newFiber的type和key来决定是复用节点、删除节点还是创建节点。在链表中，你可以很容易地沿着return指针找到对应的父节点，然后对比父节点的孩子列表。
第六章：总结——链表是通向“并发”的钥匙
好了，各位同学，我们总结一下。
为什么 Fiber 架构必须采用链表而非树状结构？
- 因为我们需要“暂停”：树状结构的深度递归是“一发入魂”，很难在执行中途保存状态。链表结构天然支持“断点续传”，我们只需要保存一个“下一个指针”即可。
- 因为我们需要“时间切片”：只有链表，才能让我们把庞大的组件树拆解成一个个微小的
workUnit（工作单元），让 React 在主线程忙碌的每一帧里都能干一点点活，干完了就歇着，干不完就下一帧继续。 - 因为我们需要“动态调度”：链表的插入、删除操作的时间复杂度是 O(1)（相对于树的 O(h)）。这使得 React 能够根据优先级，随时把高优先级的任务（如用户点击、动画）插入到渲染队列的前面，实现真正的“并发渲染”。
- 因为“回溯”很便宜：
return指针让 React 能够高效地在树的层级之间跳跃，完成 Diff 算法和协调工作，而不需要重新遍历整棵树。
所以，从树到链表，不仅仅是数据结构的变化，它是 React 从“同步阻塞”向“异步并发”转型的基石。
没有链表，就没有时间切片；没有时间切片，React 就会在复杂应用中卡顿；没有并发，就没有自动批处理，就没有现在的 React 18。
下次当你写 return <SomeComponent /> 的时候，不要只把它当成返回 JSX，想一想这背后的 Fiber 链表。这根链条，串起的不仅仅是组件，更是浏览器主线程的生命线。
感谢大家的聆听！希望大家以后面试的时候，能把这个“链表与树的决斗”讲得天花乱坠，让面试官对你刮目相看！我们下期再见！