React Fiber 树的单向链表物理拓扑：解析 child、sibling、return 指针在递归中断时的内存现场恢复

各位，把你们的咖啡杯放下，把笔记本电脑合上，我们要聊点硬核的。

今天我们不谈 CSS 布局，不谈 Hooks 的玄学，我们来聊聊 React 那个传说中的、有点像“俄罗斯方块”一样的架构——Fiber。尤其是当你深入到底层源码，你会发现 React 的渲染过程根本不是我们在函数里写的那种“顺滑”的递归，而是一场精心编排的、为了在浏览器那个苛刻的 CPU 时间片里苟延残喘的链表遍历大戏。

今天咱们就穿上潜水服，潜入 React 的内存深处，去看看那些 child、sibling 和 return 指针是如何在递归中断时，像魔术师一样把内存现场给“拉”回来的。

第一部分：递归的诅咒与链表的救赎

想象一下，你是一个强迫症患者，你的任务是给一座 100 层楼的大厦贴瓷砖。传统的递归思路是这样的：

function paintFloor(floor) {
  // 1. 贴当前层
  applyPaint(floor);

  // 2. 贴下一层
  if (floor.next) {
    paintFloor(floor.next);
  }
}

看起来挺完美，对吧？递归就是这种自带栈帧的优雅。但是，问题来了。如果这座大厦有 100 层，而你只有 16 毫秒（浏览器的单帧时间），你在贴到第 80 层的时候，浏览器大喊一声：“嘿！把控制权交给我，我要重绘一下背景！”

这时候，你的递归函数怎么办？函数调用栈里堆满了 paintFloor 的上下文，如果浏览器挂起你的 JS 执行，这些上下文就全挂了。等你回来，你得从第 1 层重新开始数数，这效率低得令人发指。更糟糕的是，如果树太深，栈溢出（Stack Overflow）直接把你炸飞。

于是，Fiber 出现了。Fiber 不是在 JS 栈上递归，而是在堆上玩链表。

它把每一个组件渲染单元（Fiber 节点）变成了一个对象，这个对象长得像这样：

{
  type: 'div',
  props: { className: 'container' },
  child: null,      // 我的第一个孩子（儿子）
  sibling: null,    // 我的兄弟（同一个爸爸的另一个孩子）
  return: null,     // 我的爸爸（通过这个指回去）
  // ... 还有一堆状态字段
}

看到了吗？这三个指针，构建了一个单向链表。但这个链表不是用来遍历循环列表的，它是用来构建和遍历树的。这种物理拓扑结构，就是实现“可中断渲染”的物理基础。

第二部分：物理拓扑的搭建——从数组到链表

咱们都知道，React 的组件树在 JS 代码里通常是个扁平的数组，比如 ['div', 'p', 'span']。Fiber 架构要把这个数组变成那个带指针的物理拓扑结构。

这过程就像是把一排士兵排好队，然后给他们插上关系牌。

假设我们有两个兄弟组件，A 和 B，它们都有一个孩子 C。

在数据层面（JS 数组）：

const children = [
  { type: A, key: 'A' },
  { type: B, key: 'B' }
];

在 Fiber 层面，我们这么干：

// 创建节点 A
const fiberA = { type: A, child: null, sibling: null, return: null };
// 创建节点 B
const fiberB = { type: B, child: null, sibling: null, return: null };

// 建立兄弟关系
fiberA.sibling = fiberB;

// 假设 A 有个孩子 C
const fiberC = { type: C, child: null, sibling: null, return: fiberA };
fiberA.child = fiberC;

现在，我们的拓扑结构是这样的：

 fiberA (return: null)
   |
   +---> fiberC (child: fiberC, return: fiberA)
   |
   +---> fiberB (sibling: fiberB, return: fiberA)

注意这个 return 指针：它不仅是父亲指向儿子，它也是儿子在递归遍历结束后的“回家路”。它是单向链表架构中，连接父子层级的关键。

第三部分：中断的艺术——如何优雅地“休息”

Fiber 核心的鬼才之处在于，它把“递归”改造成了“迭代 + 状态机”。我们可以写一个伪代码来模拟这个过程，这段代码就是 React 内部 reconciler 的灵魂。

function renderTree(fiberNode) {
  // 工作单元（Work Unit）
  while (fiberNode !== null) {

    // 1. 开始工作
    beginWork(fiberNode); // 处理这个节点，生成子节点，更新DOM等

    // 检查时间片是否用完了（模拟中断）
    if (shouldYield()) {
      // 没时间了！把当前节点挂起，把控制权交给浏览器
      return fiberNode; // 返回当前节点，这就是“现场”
    }

    // 2. 如果当前节点没有孩子，说明是叶子节点，处理完成
    if (fiberNode.child === null) {
      completeWork(fiberNode); // 比如创建 DOM 实例，挂载
    } else {
      // 3. 如果有孩子，去处理孩子
      // 这里没有递归调用！而是赋值给循环变量，进入下一轮循环
      fiberNode = fiberNode.child;
    }
  }

  // 树遍历完成
  return null;
}

看到了吗？这就是物理拓扑的奥义。我们不再依赖调用栈的栈帧来记录我们在哪一步，而是把节点对象本身的指针拿在手里。

第四部分：内存现场恢复——如何把“烂摊子”收回来

这是今天讲座的高潮部分。当你在第 50 行调用了 return fiberNode，JavaScript 引擎退出了函数。你以为世界毁灭了？不，Fiber 对象还在内存里，而且状态很完美。

现在，我们回到 renderTree 函数被浏览器中断之前的位置。我们拿到了刚才被挂起的那个节点对象，比如叫它 currentFiber。

现在的任务很明确：恢复现场，继续干活。

既然 currentFiber 没有孩子（或者孩子处理完了），它下一步该干嘛？它不能瞎逛。它看一眼 currentFiber.sibling。

场景 A：兄弟节点存在

假设 currentFiber 的兄弟 sibling 指向了 fiberB。
我们在 renderTree 里直接执行：

// 恢复现场后的逻辑
fiberNode = fiberNode.sibling; 

然后进入下一轮循环。beginWork(fiberB) 被执行。就像什么都没发生过一样，我们无缝切换到了兄弟节点。

场景 B：兄弟节点也不存在（到达叶子）

假设 currentFiber 是一个叶子节点，而且没有兄弟（比如是个 <span>）。
它的 sibling 是 null。这时候我们需要“向上回溯”。

这很关键。如果 sibling 是 null，我们怎么知道要去处理父节点？答案就是那个死死钉在内存里的 return 指针！

// 回溯逻辑
if (fiberNode.sibling === null) {
  // 到了尽头，找爸爸
  fiberNode = fiberNode.return;
}

现在，fiberNode 变成了父节点。接下来会怎么样？下一轮循环开始，beginWork 会发现父节点有多个孩子。
父节点之前已经处理完了第一个孩子（fiberNode.child），现在它看一眼自己的 sibling。

// 父节点继续干活
fiberNode = fiberNode.sibling;

这样，我们就完成了向上冒泡的过程。这个逻辑完全是由 return 指针和 sibling 指针驱动的。

第五部分：代码实战——一个可中断的渲染器

为了让你彻底明白这个机制，我们来手搓一个极简的、支持“时间切片”的渲染器。

// 1. 定义 Fiber 节点结构
class FiberNode {
  constructor(type) {
    this.type = type;
    this.child = null;   // 指向第一个子节点
    this.sibling = null; // 指向下一个兄弟节点
    this.return = null;  // 指向父节点
    this.stateNode = null; // 实际的 DOM 节点
    this.effectTag = null; // 标记修改类型
  }
}

// 模拟时间切片：如果时间不够，返回 true
let isTimeLeft = true;

function shouldYield() {
  // 在真实环境中，这里会计算 deadline
  // 现在咱们用个随机数模拟
  isTimeLeft = Math.random() > 0.5; 
  return !isTimeLeft;
}

// 模拟 beginWork：创建子节点
function beginWork(fiber) {
  console.log(`开始工作: ${fiber.type} (耗时 0ms)`);
  // 模拟创建子节点
  if (fiber.type === 'DIV') {
    // 如果是 DIV，我们给它加个 SPAN 孩子
    const childFiber = new FiberNode('SPAN');
    childFiber.return = fiber;
    fiber.child = childFiber;
  }
}

// 模拟 completeWork：处理完成，创建 DOM
function completeWork(fiber) {
  console.log(`完成工作: ${fiber.type} (创建 DOM)`);
  const dom = document.createElement(fiber.type);
  fiber.stateNode = dom;
}

// 核心渲染器
function workLoop(rootFiber) {
  // 只要还有节点，或者还有任务，循环就不停
  // 这里的 fiber 就是我们的“指针”
  let workInProgress = rootFiber;

  while (workInProgress !== null && isTimeLeft) {

    // === Phase 1: 开始构建 ===
    if (workInProgress.child === null) {
      // 如果没有子节点，开始“完成”它（比如挂载 DOM）
      completeWork(workInProgress);
      // 指针移动到兄弟节点
      workInProgress = workInProgress.sibling;
    } else {
      // 如果有子节点，先去处理子节点
      // 注意！这里不是递归调用 workLoop，而是循环变量赋值！
      workInProgress = workInProgress.child;
    }
  }

  if (workInProgress !== null) {
    // 时间没用了，把当前的节点“挂起”返回
    console.log(`>>> 时间片耗尽，挂起现场: ${workInProgress.type} <<<`);
    return workInProgress;
  } else {
    console.log(`>>> 渲染完成！所有节点已处理 <<<`);
    return null;
  }
}

// 初始化一棵树
const rootFiber = new FiberNode('DIV');
const spanFiber = new FiberNode('SPAN');
spanFiber.return = rootFiber;
rootFiber.child = spanFiber;

// 执行渲染
console.log("-------- 开始渲染 --------");
let currentFiber = rootFiber;

while (currentFiber) {
  currentFiber = workLoop(currentFiber);

  if (currentFiber) {
    // 如果 workLoop 挂起了，我们手动恢复指针继续跑
    // 在 React 源码里，这是由 Scheduler 调度器调度的
    console.log("-------- 恢复现场，继续渲染 --------");
  }
}

运行这段代码的输出模拟：
你看，在 时间片耗尽 那一步，我们的程序并没有死掉，也没有抛错。我们只是把 currentFiber 指针保留在了内存里的 spanFiber 对象上。

当浏览器释放时间片，调度器再次把我们唤醒，我们只需要把指针重新赋值给 workInProgress，下一次循环就会从 beginWork(spanFiber) 开始。

这就是内存现场恢复的实质。我们手握着 child、sibling、return 这三把钥匙，掌控着整个树的遍历节奏。

第六部分：为什么 Return 指针如此重要——向上冒泡的副作用

很多人只关注 child 和 sibling，觉得 return 只是个回溯用的。大错特错。return 指针是 React 渲染周期中副作用列表生成的关键。

还记得 React 需要在渲染结束时把 onClick、useEffect 这种副作用挂载到 DOM 上吗？这些副作用是和 DOM 节点强绑定的。

如果只是简单的递归，副作用处理是同步的：

1. 渲染子节点。
2. 渲染子节点的子节点。
3. 处理完子节点的子节点后，处理子节点的副作用。
4. 处理完子节点后，处理子节点的副作用。
5. 回到根节点，处理根节点副作用。

这个过程如果在中断时被打断（比如 return 了），React 必须知道：“好吧，我停下来的时候正在处理 span 标签。现在我恢复，我先处理 span 的副作用（如果有），然后看看 span 的兄弟，再看看 div 的兄弟……”

return 指针在这里充当了状态机的角色。当节点处理完（无论是子节点处理完，还是自己处理完），它的 return 指针会指引它去向。这种设计保证了副作用列表的生成顺序与渲染顺序严格一致。

第七部分：双缓冲技术——如何让现场恢复看起来像魔术

你可能会问：如果我在中断现场，修改了 fiberNode.child 的指向（比如在 beginWork 里做了节点复用），等恢复的时候，那岂不是乱套了？

这里就涉及到另一个高级概念了：双缓冲。

React 在内存里有两棵树：

1. Current Tree: 这是用户已经看到的、稳定的旧树。
2. WorkInProgress Tree: 这是我们正在构建的、尚未渲染的新树。

当渲染开始时，我们复用 Current Tree 的 Fiber 节点（通过 return 指针的链表回溯来找到旧节点），然后修改它的 child、sibling 指针来创建新结构。

如果在渲染过程中被挂起，WorkInProgress Tree 的指针是乱的，或者还没构建完。但是，这棵树在内存里。我们没有“丢失现场”，我们只是暂停了操作。

当调度器再次唤醒，我们从 return 指针找回旧的节点，继续修改指针。

一旦渲染完全完成，没有任何中断，React 会把 WorkInProgress Tree 变成新的 Current Tree。这一瞬间，用户的界面就更新了。旧的那棵树（如果是通过 Diff 算法复用的）可能会被垃圾回收，或者成为下一轮渲染的 WorkInProgress 的基础。

这就像导演拍电影，他脑子里有剧本（旧树），他在分镜头本上做批注（修改指针）。拍了一半，喊卡，去吃盒饭。盒饭吃完回来，继续在分镜头本上写。最后定稿，把分镜头本变成大银幕。

结语：指针的舞蹈

好了，伙计们。

当我们回顾 React Fiber 的物理拓扑时，你会发现它其实非常朴实无华。它没有魔法，只是把传统的函数调用栈，换成了显式的、可手动操纵的堆内存对象。

• child：是探险家手里的第一张地图，告诉我们要去哪里。
• sibling：是探险家背包里的备选方案，告诉我们在主路走不通时去哪。
• return：是探险家的GPS定位，告诉我们在迷路（遍历完）时如何回家。

正是这三个指针的组合，加上“时间切片”这个调度器，才让 React 能够在面对数万个节点时依然保持流畅，而不是直接崩盘。它把“递归”这种看起来无法中断的数学概念，硬生生变成了“迭代”这种可控的工程实践。

所以，下次当你看到 React 那些炫酷的动画和流畅的交互时，别只顾着感叹 UI 的美丽。去看看那堆乱七八糟的 fiberNode 对象吧，在那里，一场关于指针、内存和时间的舞蹈正在上演。这就是现代前端工程学的浪漫。