React 递归渲染向迭代遍历转化的底层实现

各位同学好，欢迎来到今天的“前端架构与底层原理”特训营。

今天我们要聊一个听起来很高大上，实际上却让你在深夜debug时头皮发麻的话题：React 的渲染机制——从“递归的幽灵”到“迭代的救星”。

如果你是 React 的老用户，你一定对 map 遍历列表，或者递归渲染树形组件不陌生。我们习惯了写这样的代码：

function TreeView({ data }) {
  return (
    <ul>
      {data.map(node => (
        <li key={node.id}>
          {node.label}
          {node.children && <TreeView data={node.children} />}
        </li>
      ))}
    </ul>
  );
}

这段代码写起来很爽，但它的底层逻辑是什么？React 内部到底是怎么跑起来的？为什么有时候树太深了，浏览器会给你报个红脸的 Maximum call stack size exceeded（堆栈溢出）？又为什么在 React 16 以后，这种递归变成了迭代，让我们有了 Concurrent Mode（并发模式）的体验？

别眨眼，今天我们不讲 API，不讲 Hooks，我们要像解剖青蛙一样，把 React 的渲染内核拆开来看。准备好了吗？让我们开始这场“从递归到迭代”的奇幻漂流。

---

第一部分：递归的诱惑与诅咒

在 React 15 时代，或者说在 Fiber 架构普及之前，React 的渲染过程本质上是一场深度优先（DFS）的递归。

想象一下，你手里有一棵树，你想把树上的叶子都涂成绿色。递归的方法是这样的：

1. 你拿起一片叶子，涂上绿色。
2. 然后问自己：“这片叶子下面还有树枝吗？”
3. 如果有，你就“递归”地进入下一层，重复步骤 1 和 2。
4. 如果没有，你就“回溯”到上一层。

在 React 的代码里，这对应着类似这样的伪代码：

// 伪代码：React 15 的递归渲染逻辑
function renderNode(node) {
  // 1. 创建 DOM 节点
  const dom = document.createElement(node.type);

  // 2. 处理属性
  for (const prop in node.props) {
    dom[prop] = node.props[prop];
  }

  // 3. 递归处理子节点（这里是重点）
  if (node.children && node.children.length > 0) {
    node.children.forEach(child => {
      // 哇，我又调用了 renderNode！
      renderNode(child); 
    });
  }

  return dom;
}

这种方法的优点是什么？
代码极其优雅，逻辑清晰。你不需要手动管理栈，不需要操心循环的边界条件。你只需要把问题分解成和自己一样的小问题，然后交给计算机去解决。

但是，这种方法的缺点是致命的。

1. 栈溢出的阴影

JavaScript 的执行是基于调用栈的。当你递归调用 renderNode 时，每一次调用都会在内存里压入一个栈帧。
如果我们的组件树有 10,000 个层级深（虽然这种情况少见，但在某些极其复杂的嵌套表单或编辑器中可能发生），或者仅仅是 React 在处理大量数据时，这个栈就会爆掉。

浏览器会直接给你弹出一个报错页面，或者更惨的是，页面直接白屏。就像你叠俄罗斯套娃，叠到第 100 层的时候，发现怎么也打不开了，只能砸碎。

2. 单线程的“卡顿”

递归是阻塞的。一旦你进入了递归，你就必须一口气把整棵树渲染完，不能停下来。
在 React 15 中，如果页面结构很复杂，JavaScript 主线程会被渲染逻辑死死锁住，导致页面掉帧、卡顿，甚至无法滚动。用户点击按钮，要等 2 秒钟才有反应。这就是典型的“同步阻塞”。

所以，React 团队觉得不行，这太脆弱了。他们需要一个既能保持递归的直观逻辑，又能像迭代一样灵活控制进度的方案。

---

第二部分：Fiber 架构——把递归“压扁”成迭代

为了解决这个问题，React 团队在 React 16 中引入了 Fiber 架构。

注意，Fiber 不是线程，它不是多线程的。Fiber 是一种数据结构，更准确地说，它是一个执行单元。

我们可以把 React 的组件树想象成一段长长的代码执行流。在 Fiber 之前，这是一条连续的线；在 Fiber 之后，它被拆成了无数个小碎片。

FiberNode 的结构：链表的艺术

Fiber 把原本“扁平”的递归调用栈，变成了一串链表。每一个 Fiber 节点都包含以下关键属性：

// FiberNode 的核心结构
class FiberNode {
  constructor(tag, type, key) {
    this.tag = tag; // 类型：函数组件、类组件、HostComponent 等
    this.type = type; // 元素类型：'div', 'span' 等
    this.key = key; // 唯一标识

    // 核心属性：构建树形结构
    this.return = null; // 父节点
    this.child = null;  // 第一个子节点
    this.sibling = null; // 下一个兄弟节点

    // 核心属性：构建执行流（这就是“迭代”的关键）
    this.index = 0;
    this.ref = null;

    // 状态相关
    this.pendingProps = null;
    this.memoizedProps = null;
    this.updateQueue = null;
    this.memoizedState = null;

    // 副作用链表
    this.effectTag = null;
    this.nextEffect = null;
  }
}

你看，这里没有 renderNode 这种函数调用。取而代之的是 this.child（子节点）和 this.sibling（兄弟节点）。

这就好比：以前我们递归是 A -> B -> C -> D，中间如果断掉，整个流程就挂了。现在 Fiber 把它变成了 A -> B -> C -> D，但是 A 和 B 之间、B 和 C 之间，都变成了指针。

递归转迭代的代码演示

现在，让我们来看看如何把上面的递归伪代码，改写成基于 Fiber 的迭代代码。

原来的递归逻辑（DFS）：

// 递归太简单了，简单到容易被滥用
function traverseTree(node) {
  if (!node) return;
  console.log("访问节点:", node.type);
  traverseTree(node.child);
  traverseTree(node.sibling);
}

现在的迭代逻辑（DFS + 显式栈）：

为了实现迭代，我们需要自己维护一个栈。

function traverseTreeIteratively(root) {
  // 1. 初始化栈，把根节点放进去
  const stack = [root];

  // 2. 开始循环
  while (stack.length > 0) {
    // 3. 取出栈顶元素（出栈）
    const node = stack.pop();

    // 处理当前节点
    console.log("访问节点:", node.type);

    // 4. 关键步骤：压入子节点
    // 注意顺序！为了保持深度优先遍历，我们要把子节点倒序压入栈
    // 这样出栈时才是先左后右，或者先子后弟
    if (node.sibling) {
      stack.push(node.sibling);
    }
    if (node.child) {
      stack.push(node.child);
    }
  }
}

看懂了吗？
这就是转化的本质。我们将“函数的自我调用”转化为了“数据的结构化存储 + 显式的循环”。

React 的 Fiber 调度器就是这么干的。它维护了一个 workInProgress 指针（当前工作节点），和一个 stack（或者叫 stackOfContexts）。

---

第三部分：时间切片——迭代带来的超能力

如果说“防止栈溢出”只是迭代的基础功能，那么时间切片就是迭代给 React 带来的超能力。

在 Fiber 之前，渲染是“一锤子买卖”。现在，因为渲染过程是迭代的（循环），React 就可以在循环的每一次迭代中，停下来。

调度器登场

React 内部有一个调度器，它的工作是帮 React 决定什么时候该干活，什么时候该休息。

// 伪代码：React 16+ 的调度循环
function workLoop(deadline) {
  // 只要还有任务，或者浏览器还没忙死（deadline.timeRemaining() > 0），就继续跑
  while (workInProgress || deadline.timeRemaining() > 0) {

    // 1. 执行一个单元的工作
    performUnitOfWork(workInProgress);

    // 2. 判断：渲染完了吗？
    if (!workInProgress && !isRootComplete) {
      // 没完，但是浏览器要处理其他事了，我们暂停一下
      // 把控制权交还给浏览器
      requestIdleCallback(workLoop);
      return;
    }
  }

  // 循环结束，提交阶段开始
  commitRoot();
}

function performUnitOfWork(fiber) {
  // 1. 创建 DOM (如果是 HostComponent)
  // 2. 处理副作用 (Effect)
  // 3. 移动指针，寻找下一个节点
  // ...

  // 寻找下一个节点：优先找兄弟，找不到找叔叔（父的兄弟），再找不到找堂弟（父的兄弟的孩子）
  if (fiber.child) {
    workInProgress = fiber.child;
  } else if (fiber.sibling) {
    workInProgress = fiber.sibling;
  } else {
    // 没有兄弟了，回溯到父节点
    workInProgress = fiber.return;
  }
}

这段代码太美妙了！

看第 2 步，deadline.timeRemaining() > 0。
这就是时间切片的核心。因为渲染是迭代的，我们可以在 while 循环里检查浏览器剩余的时间。

• 场景 A： 浏览器很闲。deadline 告诉 React：“你有 50 毫秒空闲时间。” React 就在循环里疯狂干活，渲染几千个节点。
• 场景 B： 浏览器很忙（用户在打字、滚动）。deadline 告诉 React：“你只有 5 毫秒了。” React 就说：“好的，我先暂停渲染，把控制权交给你，你先处理用户的输入。”

这就是为什么 React 16+ 在渲染复杂页面时，页面依然流畅，不会卡死的原因。它把一个大任务拆成了无数个小任务，利用浏览器的空闲时间片，见缝插针地干活。

---

第四部分：从深度优先到广度优先——副作用队列

既然我们在讲迭代，那我们不仅要提 DFS（深度优先），还要提 BFS（广度优先）。

在 React 的渲染管线中，有两类核心操作：

1. 渲染阶段： 计算、创建、比对。这是深度优先的。
2. 提交阶段： 改变 DOM、执行 useEffect。这是广度优先的。

为什么提交阶段是广度优先？

useEffect 的执行顺序很有讲究。如果你有这样的代码：

function App() {
  useEffect(() => console.log("App 1"), []);
  useEffect(() => console.log("App 2"), []);
  return <Child />;
}

function Child() {
  useEffect(() => console.log("Child"), []);
  return <div>Content</div>;
}

在 React 18 中，useEffect 的执行顺序是：App 1 -> App 2 -> Child。

为什么不是 Child -> App 1 -> App 2？
因为提交阶段是广度优先遍历。

React 维护了一个副作用队列。在渲染阶段（DFS），React 会把带有 effectTag 的节点收集起来，挂载到这个队列里。到了提交阶段，它就不再关心树的深度，而是遍历这个队列，从上到下依次执行副作用。

// 伪代码：提交阶段的广度优先遍历
function commitRoot() {
  // 1. 把根节点的 effectTag 收集到队列中
  const effectQueue = [];
  collectEffects(root, effectQueue);

  // 2. 广度优先遍历执行
  let i = 0;
  while (i < effectQueue.length) {
    const fiber = effectQueue[i];

    // 执行 DOM 更新
    commitWork(fiber);

    // 执行 useEffect
    if (fiber.effectTag & EffectTag.HasEffect) {
      executeUseEffect(fiber);
    }

    i++;
  }
}

这种设计保证了：父组件的副作用总是比子组件先执行。这对于 React 的生命周期逻辑（如 componentDidMount 顺序）至关重要。

---

第五部分：底层实现的细节——Diff 算法的迭代版

光有 Fiber 节点还不够，我们还得知道 React 是怎么“找不同”的。Diff 算法在 Fiber 时代也是迭代实现的。

双缓存树

React 在内存里维护了两棵树：

1. Current Tree（当前树）： 已经渲染在屏幕上的 DOM 对应的 Fiber 树。
2. WorkInProgress Tree（正在构建的树）： 内存中正在根据新状态生成的 Fiber 树。

Diff 的过程，就是遍历 WorkInProgress Tree，去 Current Tree 里找对应的节点。

// 伪代码：Diff 过程
function reconcileChildren(currentFiber, workInProgressFiber) {
  let alternate = currentFiber.alternate; // 旧节点
  let baseIndex = 0;
  let newChildren = workInProgressFiber.props.children;

  // 初始化两个指针
  let oldFiber = alternate ? alternate.child : null;
  let newFiber = workInProgressFiber.child;

  while (newFiber) {
    // 1. 比对 key 和 type
    const matches = newFiber.key === oldFiber.key && newFiber.type === oldFiber.type;

    if (matches) {
      // 节点类型没变，复用
      newFiber.alternate = oldFiber;
      oldFiber.alternate = newFiber;
      // 递归比对子节点
      reconcileChildren(oldFiber, newFiber);
    } else {
      // 节点类型变了，销毁旧的，创建新的
      deleteChild(oldFiber);
      createChild(newFiber);
    }

    baseIndex++;
    oldFiber = oldFiber.sibling;
    newFiber = newFiber.sibling;
  }

  // 处理多余的老节点（被删除了）
  while (oldFiber) {
    deleteChild(oldFiber);
    oldFiber = oldFiber.sibling;
  }
}

这里虽然有个 while 循环，看起来像迭代，但内部的 reconcileChildren 调用依然是递归的。

等等，这不矛盾吗？
其实不矛盾。React 的 Diff 算法本身（层级遍历）是递归的，因为它需要深入到子节点去比对。但是，调度渲染的过程是迭代的。

我们可以把 Diff 算法看作是一个黑盒。你把“新树”和“旧树”扔进去，它吐出一个“变更列表”。而 React 的调度器负责把这个黑盒“切片”执行。

---

第六部分：栈与队列的战争

既然我们都在讲迭代，那我们就要区分一下栈和队列。

在 React 的 Fiber 架构中，栈是主角，用于渲染阶段的深度优先遍历。

但是，为了处理副作用，React 还引入了队列。

还记得 EffectList 吗？当我们在组件里写 useEffect 时，React 会把当前 Fiber 节点扔进一个全局的 effectQueue 里。

• 渲染阶段： 使用栈（DFS）。为什么？因为我们要构建树的结构，父节点必须先处理完，才能确定子节点怎么处理。
• 提交阶段： 使用队列（BFS）。为什么？因为我们要把所有的 DOM 更新一次性应用到页面上，而且要按照从上到下的顺序执行副作用。

这就好比：

• 渲染阶段就像是在盖房子，必须先打好地基（父节点），才能往上砌墙（子节点）。
• 提交阶段就像是在刷油漆，先刷第一层，再刷第二层，最后刷第三层（从上到下）。

---

第七部分：实战演练——手写一个简易版 Fiber 渲染器

为了彻底搞懂这个转化，我们不看源码，我们自己写一个极简版的渲染器。这能让你秒懂 React 的本质。

目标：将一个 JSON 对象递归地转化为 HTML 字符串。

1. 递归版本（React 15 思路）

const renderRecursive = (node) => {
  if (!node) return '';

  let html = `<${node.tag}`;
  for (const key in node.props) {
    html += ` ${key}="${node.props[key]}"`;
  }
  html += `>`;

  if (node.children && node.children.length > 0) {
    node.children.forEach(child => {
      html += renderRecursive(child); // 递归调用！
    });
  }

  html += `</${node.tag}>`;
  return html;
};

// 测试
const tree = {
  tag: 'div', props: { id: 'app' },
  children: [
    { tag: 'span', props: {}, children: ['Hello'] },
    { tag: 'div', props: {}, children: [
        { tag: 'p', props: {}, children: ['World'] }
    ]}
  ]
};

console.log(renderRecursive(tree));

2. 迭代版本（React Fiber 思路）

现在，我们用栈把它改写一下。

const renderIterative = (root) => {
  // 初始化栈，放入根节点
  const stack = [root];
  let html = '';

  while (stack.length > 0) {
    const node = stack.pop(); // 出栈

    // 处理当前节点
    html += `<${node.tag}`;
    for (const key in node.props) {
      html += ` ${key}="${node.props[key]}"`;
    }
    html += `>`;

    // 关键点：压入子节点
    // 因为栈是后进先出（LIFO），为了保持 DOM 结构的正确性，
    // 我们需要把子节点**倒序**压入栈。
    if (node.children && node.children.length > 0) {
      for (let i = node.children.length - 1; i >= 0; i--) {
        stack.push(node.children[i]);
      }
    }

    html += `</${node.tag}>`;
  }

  return html;
};

console.log(renderIterative(tree));

运行结果是一样的，但逻辑变了：

1. 空间复杂度： 递归版本受限于调用栈深度（可能爆栈），迭代版本只受限于 JS 堆内存（栈数组），理论上可以处理无限深的树（只要内存够）。
2. 控制权： 在迭代版本中，你可以随时 break，随时 continue，或者暂停 stack，把控制权还给主线程。

---

第八部分：总结与升华

好了，同学们，今天我们聊了很多。

我们把 React 的渲染机制从“递归”带到了“迭代”。

为什么这么做？
因为递归太像俄罗斯套娃了，套太深了就开不开了（栈溢出），而且一旦开始套，就停不下来（阻塞）。
而迭代，就像是一辆装了变速器的卡车。我们可以根据路况（浏览器空闲时间），决定是开得快一点（时间切片），还是慢一点（让用户先点按钮），或者干脆停下来（让出主线程）。

React Fiber 的核心秘密就是：
它用链表（child, sibling, return）替代了调用栈。
它用显式栈（workInProgress 指针）替代了隐式递归。

当你下次在代码里写 map 或者递归组件的时候，不要觉得这只是简单的语法糖。你要明白，在 React 内部，它正在通过一个复杂的 while 循环，在你的数据结构上精雕细琢。它把巨大的任务切成了无数个微小的时间片，像贪吃蛇一样，一点点地吃掉 DOM 的构建过程。

这就是现代前端工程的魅力——用简单的算法解决复杂的问题，用工程化的手段对抗浏览器的物理限制。

希望大家以后看到 React.memo 或者 useMemo 时，能想到它们背后那些为了优化这个“迭代过程”而付出的努力。

下课！记得把这篇笔记转给那个总是因为递归栈溢出而崩溃的同事。