React 并发渲染：请解释 React 如何在内存中同时维护“当前展示树”和“后台计算树”的细节实现

各位下午好，欢迎来到今天的“React 内部架构解密”研讨会。

别急着把笔记本合上，我知道你们脑子里在想什么：“又是源码？又是架构图？是不是又要开始催眠了？”

打住。今天我们不聊 useEffect 的坑，也不聊 Redux 的选型，我们来聊聊 React 18 之前那个让无数人抓狂，然后被 React 团队“一剑封喉”的痛点——同步渲染。

想象一下，你是一个正在给挑剔的国王烤蛋糕的面包师。你的烤箱（浏览器主线程）一次只能烤一个蛋糕。以前，React 就像是一个只会按顺序递归的笨面包师，一旦你点了“更新”，他必须把整个蛋糕（整个组件树）一口气做完，不能停。如果蛋糕太大，或者国王这时候突然饿了（浏览器在处理其他任务），那场面就乱了——要么蛋糕烤焦了（页面卡死），要么国王饿晕了（页面无响应）。

为了解决这个问题，React 团队把这位笨面包师换成了一个多线程厨师团队。他们学会了“切蛋糕”——把大蛋糕切成小块，先烤一部分，国王饿了先吃一部分，烤完了再接着烤。

这个“切蛋糕”和“多线程”的过程，就是我们今天要讲的核心：并发渲染。

而并发渲染的灵魂，在于它在内存里同时养着两棵树：一棵是“正在展示的树”（Current Tree），另一棵是“正在后台计算的树”（Work-In-Progress Tree）。

来，我们戴上工程师的帽子，钻进 React 的内存深处，看看这两棵树是如何在同一个房间里“相爱相杀”的。

---

第一部分：为什么我们需要“两棵树”？——Fiber 的诞生

在讲两棵树之前，我们得先聊聊 React 的“骨架”。以前，React 的渲染过程就像是一条直线：A -> B -> C -> D。如果你有 1000 个组件，浏览器必须从 A 跑到 D，中间哪怕只是鼠标动了一下，React 也不能停。

为了解决这个问题，React 团队搞出了 Fiber 架构。

你可以把 Fiber 理解成 React 组件树的一个“增强版链表”。它不是把组件堆在一起，而是把每个组件都变成了一个独立的“节点”。

每个 Fiber 节点，现在都长了四条腿（属性）：

1. return：指向父节点。
2. child：指向第一个子节点。
3. sibling：指向下一个兄弟节点。
4. alternate：这是重点！它指向“兄弟树”里的对应节点。

为什么要加 alternate？因为我们要在内存里同时维护两棵树。

第二部分：内存中的双城记

现在，让我们把视线聚焦在 React 的内存堆上。

1. 当前展示树

这是用户眼睛里看到的那棵树。它是“静止”的（相对于渲染过程而言）。它代表了上一次提交后，浏览器 DOM 所在的真实状态。这棵树是稳定的，只要没有发生新的更新，它就不会变。

在代码里，这棵树通常被标记为 current。

2. 后台计算树

这是 React 的“野心”。当你触发一个更新（比如用户输入了一个字符），React 不会直接动 DOM。它会在内存里偷偷地新建一棵树。这棵树叫 workInProgress。

这棵树一开始是空的，或者说，它是以 current 树为蓝本“克隆”出来的。React 会拿着这把“蓝本”，开始计算：哪里变了？哪里需要新增？哪里需要删除？

3. 核心魔法：Alternate 引用

这是实现并发渲染最关键的一行代码。

在 React 的内部实现中，Fiber 节点是这样初始化的：

// 伪代码：Fiber 节点的构造函数
class FiberNode {
  constructor(tag, pendingProps, mode) {
    this.tag = tag; // 类型：FunctionComponent, HostRoot, etc.
    this.pendingProps = pendingProps; // 新的属性
    this.stateNode = null; // DOM 节点引用

    // --- 核心内存结构 ---
    this.return = null; // 父节点
    this.child = null;  // 第一个子节点
    this.sibling = null; // 下一个兄弟节点

    // 关键点来了：
    this.alternate = null; // 它的替身在哪里？
  }
}

当 React 开始一个更新时，它会执行类似这样的逻辑：

function createWorkInProgress(current, pendingProps) {
  // 1. 如果 current 有 alternate，说明这是第二次渲染了
  //    我们直接复用那个 alternate，把它变成新的 workInProgress
  let workInProgress = current.alternate;

  // 2. 如果没有 alternate，说明这是第一次渲染
  //    我们创建一个新的 FiberNode
  if (!workInProgress) {
    workInProgress = new FiberNode(current.tag, pendingProps, current.mode);
    workInProgress.alternate = current; // 建立双向绑定
  } else {
    // 3. 复用逻辑
    workInProgress.pendingProps = pendingProps;
    workInProgress.effectTag = 0;
    workInProgress.subtreeFlags = 0;
    workInProgress.deletions = null;
  }

  // 4. 复用子节点引用
  workInProgress.index = current.index;
  workInProgress.ref = current.ref;

  // 5. 关键步骤：把 alternate 指向 current
  //    这样 workInProgress 就知道它的“前世”是谁了
  workInProgress.alternate = current;

  // 6. 把 current 的 alternate 指向 workInProgress
  //    此时，内存里同时存在了两棵树！
  current.alternate = workInProgress;

  return workInProgress;
}

看懂了吗？这就是内存中“双城记”的建立过程。current 和 workInProgress 指向了两个不同的对象，但它们通过 alternate 属性互为镜像。

第三部分：渲染阶段的“时间切片”

有了两棵树，React 就可以开始干活了。这个过程叫“渲染阶段”。

React 不会像以前那样一口气把 workInProgress 树造完，它会把任务切分成无数个微小的任务。这些任务通过 requestIdleCallback（或者 MessageChannel）被插入到浏览器的空闲队列中。

这就好比：

• Current Tree：是已经盖好的旧房子，大家都住着呢。
• WorkInProgress Tree：是正在隔壁盖的新房子。

React 的渲染器（Scheduler）会拿着铲子，每隔几毫秒去隔壁盖一下新房子（处理一个 Fiber 节点）。

场景模拟：用户输入了 “A”

1. 初始状态：

   • 内存里只有 current 树。屏幕上显示 “Hello World”。
   • current 的根节点 HostRoot 的 alternate 指向 null。

2. 触发更新：

   • 用户输入 “A”，状态改变。
   • React 开始调度。它调用 createWorkInProgress。
   • 它在内存里创建了一个新的 HostRoot 节点，我们叫它 workInProgressRoot。
   • workInProgressRoot.alternate = currentRoot（旧树）。
   • currentRoot.alternate = workInProgressRoot（新树）。

3. 开始计算：

   • React 执行 performUnitOfWork(workInProgressRoot)。
   • 它处理了 HostRoot，发现它的 child 是 App 组件。
   • 它处理了 App，发现它的 child 是 Header。
   • 它处理了 Header，发现它的 child 是文本节点 “Hello World”。
   • 关键动作：在处理 Header 的时候，React 发现 Header 组件内部有一个状态更新（比如正在计算一个复杂的列表）。

4. 中断发生：

   • 浏览器主线程说：“哥们，我有 5ms 的空闲时间，你继续吧。”
   • React 感谢浏览器，继续处理 Header。
   • 但是，处理到一半，浏览器主线程说：“哎呀，用户点击了一下鼠标，我得处理点击事件！”
   • 中断！

5. 保存现场：

   • React 立刻停下。
   • 此时，workInProgress 树已经处理到了 Header 节点。Header 的子节点还没有处理完。
   • React 把 Header 节点从调度队列里移除。
   • 重点来了：React 不会把 workInProgress 树丢弃！它会把它保存在内存里。
   • 当用户点击事件处理完毕，浏览器再次空闲时，React 会再次调用 performUnitOfWork。
   • React 会从哪里继续？它会回到 Header 节点，从它上次停下的地方继续处理它的子节点。

6. 完成渲染：

   • 最终，workInProgress 树被完整计算完毕。
   • 这时候，React 进入“提交阶段”。

第四部分：提交阶段——树的交换

这是最惊心动魄的时刻。

渲染阶段只是在内存里算，没动 DOM。现在，React 拿着算好的 workInProgress 树，要去更新屏幕了。

1. 遍历 workInProgress 树：

   • React 发现 Header 节点有变化（比如 state 变了）。
   • 它计算出了新的子节点。

2. Diff 算法（协调）：

   • React 会对比 workInProgress 节点和它的 alternate（也就是 current 节点）。
   • 如果类型一样，复用旧节点，只更新属性。
   • 如果类型不一样，标记删除旧节点，创建新节点。

3. DOM 更新：

   • React 执行 commitRoot。
   • 它找到 workInProgress 树的根节点。
   • 它把根节点的 DOM 插入到页面。
   • 它把 Header 的 DOM 更新了。

4. 终极交换：

   • 更新完成，DOM 变成了新树的样子。
   • 现在，React 需要把 workInProgress 树变成新的 current 树。
   • 代码如下：

function commitRoot(root) {
  // 1. 把 workInProgress 树标记为 current
  //    此时，DOM 已经更新为新树的样子，用户看到的是新树
  const finishedWork = root.current.alternate;
  root.current = finishedWork;

  // 2. 把旧的 current 树标记为 workInProgress
  //    此时，finishedWork.alternate 指向的就是刚刚被踢出去的旧树
  finishedWork.alternate = root.current; // 也就是刚才的 finishedWork
  root.current.alternate = null; // 旧树的 alternate 变成 null，因为它要退休了

  // 3. 清理内存（可选，React 会做一些垃圾回收标记）
  //    ...

  // 4. 执行副作用
  //    比如 useEffect 的清理函数，挂载回调等
  flushPassiveEffects();

  // 5. 恢复调度器，准备下一次渲染
  ensureRootIsScheduled(root, eventTime);
}

你看，这就像是一场接力赛。

• 第一棒是 current（旧树），它跑完了，完成了它的使命。
• 第二棒是 workInProgress（新树），它跑完了，完成了 DOM 更新。
• 最后，裁判一声哨响：current = workInProgress。

现在，内存里又只有一棵树了。但这棵树是新的。旧的树还在 alternate 里面躺着，等待着下一次渲染时被唤醒。

第五部分：代码实战——一个极简的并发渲染器

为了让你彻底明白，我写了一个极其简化版的“并发渲染器”的代码片段。这代码肯定不能直接运行（它没有处理真实的 DOM），但它完美地复刻了“两棵树”的逻辑。

// 1. 定义 Fiber 节点
class FiberNode {
  constructor(type) {
    this.type = type; // 组件类型
    this.return = null; // 父节点
    this.child = null; // 子节点
    this.sibling = null; // 兄弟节点
    this.alternate = null; // 兄弟树里的替身
    this.stateNode = null; // 实例或 DOM
  }
}

// 2. 模拟内存中的两棵树
let currentRoot = null;
let workInProgressRoot = null;

// 3. 创建 WorkInProgress 树的核心函数
function createWorkInProgress(current) {
  if (!current) {
    // 如果没有 current，说明是第一次渲染，创建新节点
    return new FiberNode('HostRoot');
  }

  // 如果有 current，说明是第二次渲染，复用 alternate
  // 注意：这里省略了具体的属性复制逻辑，只展示引用关系
  let node = current.alternate;

  if (!node) {
    // 第一次渲染
    node = new FiberNode(current.type);
    node.alternate = current; // 建立镜像
    current.alternate = node;
  }

  return node;
}

// 4. 模拟渲染器
function render(rootElement) {
  // A. 初始化两棵树
  const rootFiber = new FiberNode('HostRoot');
  rootFiber.stateNode = rootElement; // 挂载到 DOM

  if (!currentRoot) {
    // 初始状态
    currentRoot = rootFiber;
    workInProgressRoot = createWorkInProgress(rootFiber);
  } else {
    // 更新状态
    workInProgressRoot = createWorkInProgress(currentRoot);
  }

  // B. 模拟时间切片调度
  function scheduleNextUnitOfWork() {
    // 这是一个异步函数，模拟 requestIdleCallback
    setTimeout(() => {
      // 检查是否被中断（这里简化，直接执行）
      performUnitOfWork(workInProgressRoot);

      // 如果树还没构建完，继续调度
      if (workInProgressRoot.child) {
        scheduleNextUnitOfWork();
      } else {
        // 树构建完成，进入提交阶段
        console.log("渲染完成，准备提交！");
        commitRoot();
      }
    }, 0);
  }

  scheduleNextUnitOfWork();
}

// 5. 执行一个单元工作（处理一个节点）
function performUnitOfWork(workInProgressNode) {
  console.log(`处理节点: ${workInProgressNode.type}`);

  // 模拟构建子树
  const child = new FiberNode('ChildComponent');
  workInProgressNode.child = child;
  child.return = workInProgressNode;

  // 模拟中断：在处理第二个子节点时停止
  if (workInProgressNode.type === 'ChildComponent') {
    console.log("遇到复杂计算，暂停渲染，等待浏览器空闲...");
    // 实际代码中，这里会 return，不会调用 scheduleNextUnitOfWork
    return; 
  }

  // 继续处理
  const sibling = new FiberNode('SiblingComponent');
  child.sibling = sibling;
  sibling.return = workInProgressNode;

  // 继续处理
  const text = new FiberNode('Text');
  sibling.child = text;
  text.return = sibling;

  // 继续处理
  const grandChild = new FiberNode('GrandChild');
  text.child = grandChild;
  grandChild.return = text;
}

// 6. 提交阶段
function commitRoot() {
  // 此时 DOM 已经更新为 workInProgressRoot 的样子
  // 这里我们只是打印一下，表示交换完成
  console.log("交换 current 和 workInProgress");
  const nextRoot = workInProgressRoot;
  workInProgressRoot = currentRoot;
  currentRoot = nextRoot;

  // 清理 alternate 引用（简化）
  currentRoot.alternate = null;
}

// 运行测试
console.log("--- 开始渲染 ---");
render(document.body);

代码解析：

1. createWorkInProgress：这就是那个魔术师。它确保无论你触发多少次渲染，内存里永远有两棵树在互相引用。
2. performUnitOfWork：这是那个勤劳的工人。他每次只干一点点活，干累了就喊“休息一下”（return）。
3. scheduleNextUnitOfWork：这是那个调度员。他负责在浏览器空闲时把工人叫回来继续干活。
4. commitRoot：这是那个收尾的。他看着工人干完了活，就把工人的成果（新树）变成正式的成果（current），把旧成果扔进仓库（alternate）。

第六部分：为什么这很重要？

你可能会问：“为什么要搞这么复杂？直接同步渲染完不就行了吗？”

这就要回到并发渲染的初衷了。

1. 高优先级任务的插队：
   以前，如果有一个低优先级的更新正在渲染（比如一个巨大的列表重排），用户突然点击了一个按钮（高优先级，比如提交表单）。React 会傻傻地等列表渲染完再处理点击。结果就是用户点击没反应。
   有了并发渲染，React 可以中断低优先级的列表渲染，把 CPU 抢过来处理高优先级的点击事件。当点击事件处理完，React 再回来，从上次中断的地方继续渲染列表。

2. 用户体验：
   想象一下，你在看一个视频，视频卡顿了 500 毫秒。这 500 毫秒可能只是因为页面在计算一个复杂的动画。并发渲染可以让这个计算被打散，让浏览器有足够的时间去渲染视频帧，保证视频不卡，同时悄悄把动画算完。

第七部分：内存泄漏与副作用

这里有一个很重要的细节，涉及到内存和副作用。

当 React 在渲染阶段中断时，它把 workInProgress 树保存在内存里。但是，workInProgress 树里的组件实例（比如 class Component 的实例）并没有被销毁。

这就带来了一个问题：副作用。

如果一个组件在 useEffect 里订阅了数据，或者开启了一个定时器，而 React 因为中断而丢弃了 workInProgress 树，那么这个组件实例在内存里就“活”着，但它的 effect 还在跑。

React 的处理方式非常优雅：在提交阶段，React 会执行所有的“卸载”和“挂载”逻辑。

当 commitRoot 执行时：

1. React 会对比 workInProgress 和 current。
2. 如果某个节点在 workInProgress 里存在但在 current 里不存在，说明是新挂载的。React 会执行它的 useEffect（挂载回调）。
3. 如果某个节点在 current 里存在但在 workInProgress 里不存在，说明被删除了。React 会执行它的 useEffect 清理函数。

所以，虽然内存里同时有两棵树，React 依然能保证副作用被正确地触发和清理。这就像你装修房子，旧家具（旧树）被搬走了，新家具（新树）被搬进来了。装修队（副作用）只在换家具的时候干活，不会一直住在房子里。

第八部分：总结——一场精妙的舞蹈

好了，各位，我们已经把 React 并发渲染的内存模型扒了个精光。

React 的并发渲染，本质上是一场精心编排的舞蹈。

• 舞台：浏览器的内存堆。
• 演员：Fiber 节点。
• 舞伴：current 和 workInProgress。
• 舞步：createWorkInProgress（镜像生成），performUnitOfWork（时间切片），commitRoot（树的交换）。

React 以前是一个只会死磕到底的莽夫，现在变成了一位懂得“见好就收”的绅士。它不再执着于一次性算完所有东西，而是学会了把任务拆碎，利用浏览器的碎片时间，在保证主线程流畅的同时，悄悄完成复杂的计算。

这就是为什么 React 能在处理数万个节点时依然保持响应。因为它的每一颗 Fiber 节点，都在时刻准备着“暂停”和“继续”，在内存的两棵树之间，编织出一张流畅的网。

现在，当你下次点击 setState 时，请记住：在屏幕闪烁的那一瞬间，你的浏览器里，正有两棵树在为了你的体验，进行着一场无声的接力赛。

谢谢大家，我是你们的资深编程专家，我们下次再见！