React Fiber 树深度优先遍历源码分析

各位同学，大家下午好！

今天我们要聊点硬核的。别慌，我保证今天不讲怎么写一个 Hello World，也不讲怎么用 useState 做个计数器。我们要深入 React 的最核心、最神秘、也是最让初学者“头秃”的地方——Fiber 架构。

特别是，我们要像拿着手术刀一样，去解剖它的深度优先遍历（DFS）源码。

你们知道吗？在 React 15 之前，React 的渲染就像是一个任性的厨师。你给他一道复杂的菜谱（一个巨大的组件树），他如果不做完，绝不吃下一口。结果呢？浏览器卡死，用户只能看着那个转圈圈的小球发呆。那时候的 React，虽然快，但不够“平滑”。

直到 React 16，Meta 的工程师们祭出了大招——Fiber。他们把那个“任性的厨师”变成了一个“极度自律的工人”。这个工人会严格按照时间切片来工作，做完一部分就停下来喘口气，把剩下的活儿交给浏览器去调度。

而这个工人的工作逻辑，就是我们要讲的——深度优先遍历。

准备好了吗？把你们的咖啡倒满，我们把代码剥个精光。

---

第一部分：Fiber 到底是个什么鬼？

在讲遍历之前，我们必须得搞清楚 Fiber 到底长什么样。

如果你以前学过数据结构，你可能会想：“React 节点不就是树吗？父节点指向子节点，子节点指向父节点。”

错！大错特错！

在 React Fiber 的世界里，树只是我们用来理解它的一个概念模型。在内存里，Fiber 根本不是一棵树，它是一个单链表！

想象一下，你是一个工厂的厂长。你面前有一堆待加工的零件（组件）。

• 每个零件都有一个“子零件”（child）。
• 如果子零件处理完了，厂长会去看“兄弟零件”（sibling）。
• 如果兄弟零件也处理完了，厂长才回到“父零件”（return），告诉它：“嘿，你的孩子处理完了，接下来该你干活了。”

这就是 Fiber 节点的结构：

// 这是一个简化版的 Fiber 节点
class FiberNode {
  // 指向下一个兄弟节点（右边的表兄弟）
  sibling: FiberNode | null;

  // 指向第一个子节点（左边的孩子）
  child: FiberNode | null;

  // 指向父节点（用来回溯）
  return: FiberNode | null;

  // 节点类型，比如 'div', 'span', 'function'
  type: any;

  // 状态标记，决定了这个节点该干嘛
  effectTag: number;

  // ...
}

看到没有？没有指针指向上面的兄弟，只有指针指向下面的兄弟。这就是链表。

第二部分：为什么要深度优先遍历？

既然是链表，我们怎么遍历它？怎么找到该干活的节点？

答案很简单：深度优先遍历（DFS）。

为什么是 DFS？因为 React 的协调逻辑是“先处理子元素，再处理父元素”。就像你读一本书，你得先读完第一章，才能读第二章。你不能跳过第一章直接看第三章，因为你不知道第二章里发生了什么。

在 React 的世界里，这意味着：

1. 先处理当前节点的 child（孩子）。
2. 如果孩子处理完了，处理 sibling（兄弟）。
3. 如果兄弟也处理完了，回到 return（父节点），让父节点继续它未完成的工作。

这就是 DFS 的精髓：走到黑，遇到死胡同再回头。

第三部分：从递归到迭代——一场“痛苦”的蜕变

在 Fiber 出现之前，React 使用的是递归。代码长这样：

function renderTree(node) {
  if (!node) return;

  // 1. 处理自己
  console.log("处理自己:", node.name);

  // 2. 递归处理孩子
  renderTree(node.child);

  // 3. 递归处理兄弟
  renderTree(node.sibling);
}

递归多香啊！代码简洁，逻辑清晰。但是，对于 React 这种要渲染几万个 DOM 节点的应用，递归是灾难。如果递归太深，JavaScript 的调用栈就满了，浏览器就会崩溃（Stack Overflow）。

Fiber 的工程师们忍痛割爱，抛弃了递归，转而使用手动栈来模拟递归。这就是我们今天要讲的 performUnitOfWork 函数。

第四部分：核心源码解剖——performUnitOfWork

这是整个 React 渲染循环的灵魂。我们来看看源码（简化版）：

function performUnitOfWork(workInProgress: FiberNode): FiberNode | null {
  // 1. 开始工作
  const next = beginWork(workInProgress);

  // 如果 beginWork 返回了子节点，说明我们找到了新的工作目标
  if (next !== null) {
    return next; 
  }

  // 2. 如果没有子节点了，说明这个节点处理完了
  // 开始处理兄弟节点
  return completeUnitOfWork(workInProgress);
}

等等，这看起来好像还是递归的感觉？别急，这只是第一层。真正的魔法在于 completeUnitOfWork 里，它是如何处理“兄弟节点”和“父节点”的。

第五部分：completeUnitOfWork —— 回溯的艺术

当 beginWork 返回 null 时，意味着当前节点已经没有子节点了（或者所有子节点都处理完了）。这时候，我们需要向上回溯，去找这个节点的兄弟节点。

这就是 Fiber DFS 的关键逻辑：

function completeUnitOfWork(workInProgress: FiberNode): FiberNode | null {
  let completedWork = workInProgress;

  // 1. 标记当前节点完成（比如收集副作用）
  completeWork(completedWork);

  // 2. 寻找下一个工作单元
  // 我们要找这个节点的兄弟节点
  let sibling = completedWork.sibling;

  if (sibling !== null) {
    // 找到了兄弟！太好了，把工作交给兄弟，当前节点不用管了
    return sibling;
  }

  // 3. 没有兄弟了？说明我是这一组兄弟里的最后一个孩子。
  // 那么我要去找我的父节点，把我的状态告诉父节点。
  let returnFiber = completedWork.return;

  if (returnFiber !== null) {
    // 父节点还在等待我呢。把我的兄弟（也就是当前节点）传给父节点，
    // 让父节点去处理下一个兄弟。
    returnFiber.sibling = sibling; // 其实是 null

    // 返回父节点，让父节点继续它的 beginWork
    return returnFiber;
  }

  // 4. 如果 returnFiber 也是 null，说明我们回到了根节点。
  // 整棵树的遍历结束了！
  return null;
}

代码流程模拟

假设我们有这么一棵树（A -> B -> D, E -> C -> F）：

      A (Root)
     / 
    B   C
   / 
  D   E

初始状态： nextUnitOfWork = A

第一轮循环：

1. beginWork(A) -> 返回 B。
2. performUnitOfWork 返回 B。

第二轮循环：

1. beginWork(B) -> 返回 D。
2. performUnitOfWork 返回 D。

第三轮循环：

1. beginWork(D) -> D 没有孩子，返回 null。
2. 调用 completeUnitOfWork(D)：
   • D 没有兄弟。
   • D 的父节点是 B。
   • 返回 B。

第四轮循环：

1. beginWork(B) -> B 已经处理过 D 了，现在处理 E。
2. beginWork(E) -> E 没有孩子，返回 null。
3. 调用 completeUnitOfWork(E)：
   • E 没有兄弟。
   • E 的父节点是 B。
   • 返回 B。

第五轮循环：

1. beginWork(B) -> B 的孩子 D 和 E 都处理完了，返回 null。
2. 调用 completeUnitOfWork(B)：
   • B 没有兄弟。
   • B 的父节点是 A。
   • 返回 A。

第六轮循环：

1. beginWork(A) -> A 的孩子 B 处理完了，现在处理 C。
2. beginWork(C) -> 返回 F。
3. performUnitOfWork 返回 F。

第七轮循环：

1. beginWork(F) -> 没孩子，返回 null。
2. completeUnitOfWork(F) -> 返回 C。

第八轮循环：

1. beginWork(C) -> C 没孩子了，返回 null。
2. completeUnitOfWork(C) -> 返回 A。

第九轮循环：

1. beginWork(A) -> A 的孩子 B 和 C 都处理完了，返回 null。
2. completeUnitOfWork(A) -> 返回 null。

循环结束！

看到了吗？这就是 DFS！我们深入到了最底层的 D，然后一路回溯到 B，再深入到 E，回溯到 B，然后去处理 A 的另一个孩子 C。

第六部分：时间切片——Fiber 的灵魂

好，刚才我们讲了逻辑。现在我们要讲讲如何实现时间切片。

React 不会一口气把上面的循环跑完。它在 performUnitOfWork 里面加了一个时间检查。

function workLoopConcurrent() {
  while (nextUnitOfWork !== null) {
    // 每次执行一个单元工作后，检查是否还有时间
    if (shouldYield()) {
      // 时间到了！暂停！
      // 把 nextUnitOfWork 保存起来，下次浏览器空闲了再回来。
      return;
    }

    // 继续干活
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }
}

这里用到了浏览器原生的 API requestIdleCallback。它会告诉浏览器：“嘿，现在浏览器空闲了，你给 React 5ms 时间去跑一下渲染逻辑。”

这就解释了为什么 React 16+ 在处理复杂列表时，页面不会卡死。因为它把大任务切碎了，像切香肠一样，一口一口地吃。

第七部分：Effect List——副作用收集

深度优先遍历还有一个非常重要的目的：收集副作用。

React 需要知道哪些节点被插入了，哪些被删除了，哪些属性变了。这些信息被保存在 effectTag 里。

在 completeUnitOfWork 阶段，React 会做一件非常重要的事情：建立 Effect List。

逻辑是这样的：

1. 当一个子节点处理完（completeUnitOfWork 被调用），它会把自己的副作用标记（child.effectTag）加到父节点上。
2. 如果子节点有兄弟，父节点会继续把兄弟的副作用也加进来。

这听起来很绕，我们看代码：

function completeUnitOfWork(workInProgress: FiberNode) {
  // ... 前面的逻辑 ...

  // 获取当前节点的第一个子节点
  const child = workInProgress.child;

  if (child !== null) {
    // 如果有子节点，把子节点挂到父节点的 effectList 里
    // 这一步至关重要，它把子节点的副作用“继承”给了父节点
    workInProgress.effectTag |= child.effectTag;
    return child;
  }

  // ... 后面的逻辑 ...
}

为什么这么做？因为 React 最后渲染 DOM 时，不是从根节点往下渲染的，而是从叶子节点往上渲染的。

想象一下，你要给一棵树挂灯笼。

1. 你不能从树根开始挂，因为树根挂了，树枝挂不了。
2. 你得先从叶子开始挂，挂好叶子，再挂树枝，最后挂树根。

Fiber 的 Effect List 就是为了确保这种后序遍历（Post-order DFS）的渲染顺序。

第八部分：完整代码模拟实战

为了彻底搞懂，我们来手写一个简化版的 React 渲染器。假设我们有一个组件树，我们要把它“遍历”一遍。

// 1. 定义 Fiber 节点
class FiberNode {
  constructor(type, returnNode = null) {
    this.type = type; // 'div', 'span'
    this.return = returnNode; // 父节点
    this.child = null; // 第一个子节点
    this.sibling = null; // 下一个兄弟节点
    this.effectTag = 0; // 0: 无, 1: 插入, 2: 更新
    this.effectList = []; // 副作用列表
  }
}

// 2. 模拟 beginWork：创建子节点
function beginWork(current, workInProgress) {
  if (!current) {
    // 如果是首次渲染，创建子节点
    const child = new FiberNode('span', workInProgress);
    workInProgress.child = child;
    return child;
  }
  // ... 简化逻辑，忽略更新逻辑 ...
}

// 3. 模拟 completeWork：处理节点完成
function completeWork(workInProgress) {
  // 将当前节点的 effectTag 加入到父节点的 effectList
  if (workInProgress.return) {
    workInProgress.return.effectList.push(workInProgress);
  }
}

// 4. 核心调度循环
function workLoop() {
  while (nextUnitOfWork) {
    // 执行工作单元
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
  }
}

function performUnitOfWork(workInProgress) {
  // Step 1: 开始当前节点的工作（创建子节点）
  nextUnitOfWork = beginWork(null, workInProgress);

  if (!nextUnitOfWork) {
    // Step 2: 如果没有子节点，说明当前节点处理完了
    // 开始回溯逻辑
    return completeUnitOfWork(workInProgress);
  }

  // Step 3: 如果有子节点，返回子节点，继续深入
  return nextUnitOfWork;
}

// --- 模拟开始 ---

// 构建一棵树: A -> B -> D, E -> C
const A = new FiberNode('div');
const B = new FiberNode('div', A);
const C = new FiberNode('div', A);
const D = new FiberNode('span', B);
const E = new FiberNode('span', B);

A.child = B;
B.sibling = C;
B.child = D;
D.sibling = E;

let nextUnitOfWork = A;

console.log("开始渲染流程...");
workLoop();

// 检查结果：A 的 effectList 应该包含所有叶子节点
console.log("A 的 effectList:", A.effectList); 
// 输出: [ FiberNode { type: 'span' }, FiberNode { type: 'span' } ]
// 注意：D 和 E 是叶子节点，它们被挂到了 A 下面！

看！这就是 DFS 的威力。虽然我们是从 A 开始的，但最终收集到的副作用列表，是按照后序遍历顺序（叶子 -> 根）排列的。

第九部分：深入细节——return 指针的妙用

很多同学对 Fiber 的 return 指针感到困惑。为什么要有这个指针？

因为在 completeUnitOfWork 中，当我们处理完一个节点，要去找它的兄弟时，如果我们没有 return 指针，我们就得在内存里通过某种算法去搜索“谁是我的父节点”。这太慢了！

有了 return 指针，回溯就变成了简单的指针赋值：

// 在 completeUnitOfWork 中
if (returnFiber !== null) {
  // 告诉父节点：“兄弟节点处理完了，把我的状态传给你，然后你去找下一个兄弟吧。”
  returnFiber.sibling = sibling;
  // 然后把父节点交还给调度器，让调度器继续处理父节点
  return returnFiber;
}

这个过程就像是：

1. 你在左边草丛里找虫子（处理子节点）。
2. 找不到虫子了，你退出来，告诉左边的草丛主人：“虫子没了，我走了。”
3. 草丛主人说：“那你看看右边草丛有没有？”
4. 你走到右边草丛找虫子。
5. 右边也没有，你告诉主人：“右边也没有。”
6. 草丛主人说：“行吧，那我也该去找我自己的兄弟了。”

这个 return 指针，就是连接这些草丛的绳子。

第十部分：总结——Fiber 架构的优雅之处

好了，我们绕了一大圈，从链表结构讲到深度优先遍历，又讲到时间切片。

React Fiber 的深度优先遍历，本质上是一种手动的栈模拟。

它抛弃了递归的便利，换取了可中断性。通过把巨大的渲染任务拆解成一个个微小的 Fiber 节点，通过链表的指针导航，React 实现了：

1. 高精度调度：精确到几毫秒的时间切片。
2. 平滑的动画：主线程不会被长时间占用，UI 响应依然灵敏。
3. 精确的副作用收集：利用后序遍历的特性，完美解决了父子渲染顺序的问题。

下次当你看到 React 的 render 函数在疯狂调用时，不要只觉得它是一个函数。你要知道，在 React 内部，有一个不知疲倦的调度器，手里拿着一个链表，正按照深度优先的路线，在代码的丛林里，一步一个脚印地，把你写的组件树，从根节点修剪到叶子节点。

这就是 React Fiber，这就是深度优先遍历的源码之美。

希望大家以后写代码时，也能像 Fiber 一样：深入细节，及时回溯，稳扎稳打，不慌不忙。

今天的讲座就到这里，下课！