React Fiber 节点 alternate 指针复用策略：一场关于“时间旅行者”的深度讲座

各位 React 爱好者，欢迎来到今天的“React 内部架构秘密花园”讲座。

我是你们的主讲人，一个在 React 源码里摸爬滚打多年的“老油条”。今天我们不聊怎么写 useEffect，也不聊怎么调优 useMemo。我们要聊的是 React 的灵魂——Fiber 架构中最迷人、最精妙，甚至有点像“时间旅行”的功能：alternate 指针。

你们有没有想过，当你在点击按钮的时候，React 是怎么知道“哎呀，这个 DOM 节点其实没变，别动它”，还是“嘿，这个节点换了位置，我要挪一下”？它难道每次都像个小偷一样，把整个 DOM 树都翻一遍吗？

当然不是。React 是个优雅的绅士，它用的是指针，而不是大刀阔斧的克隆。

而 alternate，就是那个让 React 能够在“当前世界”和“未来世界”之间自由穿梭的导航员。

---

第一部分：Fiber 的前世今生——为什么我们需要一个“指针”？

在 Fiber 出现之前，React 还是个“同步怪兽”。你想更新一个状态，React 就得把你的组件树从上到下、从左到右，像遍历数组一样遍历一遍。如果树很深，主线程就被卡住了，页面就会卡顿，用户体验就像是在泥潭里走路。

后来，Dan Abramov（也就是我们的“React 老大”）发话了：“我们要异步渲染！”于是，React Fiber 诞生了。

Fiber 把那个巨大的组件树，拆解成了一个个小碎片，我们称之为 Fiber 节点。每个 Fiber 节点都是一个独立的 JavaScript 对象，它包含着组件的类型、状态、DOM 引用，还有它的子节点、兄弟节点、父节点。

关键来了：
普通的链表是单向的（头 -> 尾），但 React 的 Fiber 树是个双向链表！为什么？因为 React 需要倒着工作，从叶子节点往回找。

每个 Fiber 节点都有一个属性叫 alternate。

// 想象中的 Fiber 节点结构
interface FiberNode {
  // ... 其他属性：type, key, stateNode, props, ...

  // 指向兄弟节点
  sibling: FiberNode | null;

  // 指向父节点
  return: FiberNode | null;

  // 指向子节点
  child: FiberNode | null;

  // 核心！这个指针指向“过去”或者“未来”
  alternate: FiberNode | null;
}

这个 alternate 到底是干嘛的？简单说，它是一面镜子。

在 React 的渲染循环中，时刻有两个世界在打架：

1. Current Tree（当前树）： 也就是屏幕上已经显示的树，它是稳定的，是“过去”。
2. WorkInProgress Tree（正在构建的树）： React 正在脑子里构思的树，它是临时的，是“未来”。

当你调用 setState 时，React 并没有把 Current Tree 扔进垃圾桶。它只是创建了一个 WorkInProgress Tree，并且把 Current Tree 里的节点作为 WorkInProgress Tree 节点的 alternate。

---

第二部分：代码实战——构建“时间旅行”的桥梁

让我们来写一段伪代码，模拟一下 React 是怎么创建这些节点的。这可是重头戏。

假设我们有一个父组件 <App />，里面有一个子组件 <List />，里面有三个列表项 <Item />。

1. 初始化阶段：Current 树

当你的页面第一次加载时，current 指针指向这些节点。此时，alternate 都是 null。

// 初始渲染
const currentRoot = createFiberRoot();
const currentFiber = createFiber({
  type: App,
  alternate: null, // 初始时没有过去
  child: listFiber,
  stateNode: container
});

currentRoot.current = currentFiber;

2. 更新阶段：WorkInProgress 树与 Alternate 的诞生

现在，你的 App 组件接收到了新的 props，比如用户输入了新的数据，App 决定重新渲染。React 开始执行 reconciler（协调器）。

第一步：克隆节点

React 不会凭空捏造节点。它会先从 current 树里把对应的节点“借”过来。

function reconcileChildren(currentFiber, newChildren) {
  // 假设我们遍历到了 App 的子节点
  const newFiber = {
    type: List, // 新的类型
    key: null,
    alternate: currentFiber, // 关键！新节点的 alternate 指向旧节点
    child: null,
    sibling: null,
    return: currentFiber
  };

  // 关键！旧节点的 alternate 指向新节点
  currentFiber.alternate = newFiber;

  // WorkInProgress 树的根指向新节点
  workInProgressRoot.current = newFiber;
}

看懂了吗？alternate 就像是一条隐形的红线，把新树和旧树连在了一起。新节点说：“嘿，兄弟，我知道你是谁，我是你的未来。” 旧节点说：“好的，我会支持你。”

---

第三部分：Diffing 算法——如何利用 Alternate 进行“比对”？

这是 alternate 最大的价值所在。React 的 Diff 算法（协调算法）非常高效，它的核心逻辑就是复用。

当 React 遍历新列表 [Item1, Item2, Item3] 时，它需要对比旧列表 [ItemA, ItemB, ItemC]。它怎么知道 Item1 对应的是 ItemA 呢？

它通过 alternate。

场景一：类型未变，只是属性变了

比如你的 <List /> 组件没有变化，只是里面的文本变了。

// 旧节点
const oldFiber = {
  type: Item, // 组件类型没变
  key: 'A',
  alternate: null, // 如果是第一次渲染，alternate 是 null
  props: { text: 'Old Text' },
  stateNode: domNode // 指向真实的 DOM
};

// 新节点
const newFiber = {
  type: Item,
  key: 'A',
  alternate: oldFiber, // 新节点的 alternate 指向了旧节点
  props: { text: 'New Text' },
  stateNode: null
};

// React 的比对逻辑（简化版）
function updateNode(oldFiber, newFiber) {
  // 1. 检查类型
  if (newFiber.type !== oldFiber.type) {
    console.log("类型变了，得销毁重建！");
    return createFiber(newFiber.type, newFiber.key, newFiber.props);
  }

  // 2. 类型没变，复用！
  // 因为 newFiber.alternate 存在，说明我们在更新阶段
  // 我们可以直接复用 DOM 节点
  newFiber.stateNode = oldFiber.stateNode; // 复用 DOM 引用
  newFiber.effectTag = 'UPDATE'; // 标记为更新操作

  // 3. 更新 props
  newFiber.props = newFiber.props; // React 会对比 props 并更新 DOM

  return newFiber;
}

在这个例子中，alternate 告诉 React：“嘿，别给我建新的 DOM 节点了，直接用那个旧的 DOM 节点，把里面的文字改一下就行。”

性能提升： 避免了昂贵的 DOM 挂载和卸载操作。

场景二：列表项移动了位置

这是 React 最强的地方。假设旧列表是 [A, B, C]，新列表变成了 [B, C, A]。

React 会遍历新列表：

1. 看到 B。它去 B 的 alternate（也就是旧列表的 B）那里看。找到了！类型一样，Key 一样。复用！ React 记录下来：B 还在原来的位置，只是往后挪了。
2. 看到 C。它去 C 的 alternate（也就是旧列表的 C）那里看。找到了！复用！
3. 看到 A。它去 A 的 alternate（也就是旧列表的 A）那里看。找到了！复用！

React 甚至不需要计算复杂的矩阵，它只需要把 B 和 C 的 sibling 指针连起来，把 A 插到末尾。

场景三：Key 的作用

alternate 的比对依赖于 key。如果新节点没有 key，React 就只能粗暴地按顺序比。如果有 key，React 就能通过 key 找到 alternate。

// 如果 key 不匹配，React 会认为这是两个完全不同的节点
if (newFiber.key !== oldFiber.key) {
  console.log("Key 不匹配，这可能是新增或删除，不是移动！");
  return createFiber(newFiber.type, newFiber.key, newFiber.props);
}

---

第四部分：深入源码逻辑——Alternate 的生命周期

为了让大家更透彻地理解，我们来模拟一下 React 的渲染周期，特别是 alternate 的变化。

1. Render Phase（渲染阶段）

在这个阶段，React 只是在内存里构建 WorkInProgress Tree。它疯狂地创建新节点，疯狂地利用 alternate 进行复用。

function reconcileChildFibers(current, workInProgress, nextChildren) {
  // current 是 Current Tree 的根
  // workInProgress 是 WorkInProgress Tree 的根

  // 我们要遍历 nextChildren（新的 JSX）

  let index = 0;
  let lastPlacedIndex = 0; // 记录上一次复用节点的位置
  let deletedChildren = null; // 待删除的节点列表

  while (index < nextChildren.length || deletedChildren !== null) {
    const currentFiber = current !== null ? current[index] : null;
    const newFiber = workInProgress[index];

    if (newFiber === null) {
      // 新列表比旧列表长 -> 新增节点
      const createdFiber = createFiber(newFiber.type, newFiber.key, newFiber.props);
      createdFiber.effectTag = 'PLACEMENT';
      // 注意：这里没有设置 alternate！因为新节点是凭空产生的
      workInProgress[index] = createdFiber;
      index++;
    } else if (currentFiber === null) {
      // 旧列表比新列表长 -> 删除节点
      // deletedChildren 链表处理
      deletedChildren = deleteChild(currentFiber, deletedChildren);
      current = current.sibling;
      index++;
    } else {
      // 两者都有 -> 尝试复用
      if (currentFiber.alternate !== null) {
        // 这是一个关键点！如果 alternate 存在，说明这是一个更新
        // 我们可以直接复用
        const existing = currentFiber.alternate;

        // 简单的 Diffing
        if (existing.type === newFiber.type && existing.key === newFiber.key) {
            // 复用逻辑...
            newFiber.stateNode = existing.stateNode; // 复用 DOM
            newFiber.effectTag = 'UPDATE';
            // ...省略 props 对比
        }
      }

      // 如果复用失败，或者没有 alternate，就创建新的
      // currentFiber.alternate = newFiber; // 旧节点的 alternate 指向新节点
      // newFiber.alternate = currentFiber; // 新节点的 alternate 指向旧节点

      index++;
    }
  }
}

2. Commit Phase（提交阶段）

这是 React 唯一真正触碰 DOM 的时刻。在提交阶段开始前，有一个神奇的魔法。

function commitRoot(root) {
  // 1. 交换指针
  // 这是一个原子操作（在 JS 单线程中）
  // 把 WorkInProgress 树变成 Current 树

  const previousCurrent = root.current;
  root.current = root.workInProgress;

  // 2. 清理 alternate 指针
  // 提交完成后，WorkInProgress 树变成了 Current 树。
  // 旧的 Current 树（previousCurrent）就变成了 WorkInProgress 树（为了下一次更新做准备）。
  // 所以，previousCurrent.alternate 需要被置为 null，因为它现在是一个全新的根节点了。

  if (previousCurrent.alternate !== null) {
      previousCurrent.alternate = null;
  }

  // 3. 更新 DOM
  commitAllHostEffects(root.current);
}

这个指针交换太精妙了！
想象一下：

• 旧状态： Current 指向 Tree A。
• 更新触发： React 构建 Tree B。
• 渲染中： Current 指向 Tree B（但屏幕上还是 Tree A），Tree B 的 alternate 指向 Tree A。
• 提交时： React 交换指针。Current 变回指向 Tree A（因为树没变，只是内容变了）。
• 下一次更新： React 构建 Tree C。Tree C 的 alternate 指向 Tree A（因为 Tree A 现在是 Current 了）。

alternate 就像是一个接力棒。每一帧渲染，接力棒都在传递，但树本身（节点对象）大部分时间都在原地待命，只是换了个主人。

---

第五部分：Alternate 的“坑”与“妙招”

作为一个资深专家，我必须告诉你们，虽然 alternate 很强，但用不好也会翻车。

坑一：不要在函数组件里“作弊”

有些同学喜欢在组件外部定义变量，试图在渲染之间保持状态。这会导致 alternate 逻辑失效。

let count = 0; // 这是一个闭包陷阱！

function Counter() {
  count++; // 每次渲染都加，这根本不是 React 的状态管理！

  return <div>{count}</div>;
}

在这个例子中，每次渲染 Counter，React 都会认为这是一个全新的组件，因为 count 变量不在 Fiber 节点的 memoizedState 里。React 无法通过 alternate 复用 DOM，导致每次都重绘。

坑二：Key 的滥用

虽然 alternate 能处理移动，但如果你乱用 Key，React 会崩溃或者表现异常。

// 错误示例：用 index 作为 key
{items.map((item, index) => <div key={index}>{item.name}</div>)}

// 当你删除中间的项时：
// 旧列表: [A(index 0), B(index 1), C(index 2)]
// 新列表: [B(index 0), C(index 1)]
// React 看到 B 的 key 是 0，会以为它是第一个元素，去旧列表找 key 为 0 的元素（也就是 A）。
// 发现类型不匹配，于是销毁 A，创建 B。
// 这导致 B 和 C 都被销毁重建了，而不是移动！

在这种情况下，alternate 指针虽然存在，但 React 的 Diff 逻辑因为 Key 的误导，无法正确复用。所以，永远使用唯一的 ID 作为 Key，这是对 alternate 策略最大的尊重。

妙招：使用 useMemo 和 useCallback 的底层逻辑

你们知道为什么 useMemo 能缓存结果吗？因为它利用了 alternate 的机制。

当组件重新渲染时，React 会创建一个新的 Fiber 节点。如果 useMemo 的依赖项没变，React 会发现新节点的 alternate 存在，并且 memoizedState 里的值是一样的。于是，React 会直接复用旧节点的 memoizedState，而不重新执行函数。

这就是为什么 useMemo 能省电的原因——它阻止了计算逻辑的执行，同时也阻止了不必要的子组件重新渲染。

---

第六部分：并发模式下的 Alternate

在 React 18 引入的并发模式中，alternate 的作用变得更加重要，也更加复杂。

在并发模式下，React 可以在渲染过程中被打断（比如用户快速点击了两次按钮）。

1. 第一次点击： React 开始构建 WorkInProgress Tree。它利用了 alternate。
2. 被打断： 浏览器空闲下来，React 把控制权交出去。
3. 第二次点击： React 再次开始渲染。它再次从 Current Tree 开始，创建新的 WorkInProgress Tree。

这里有个巨大的性能优化点：

在并发模式下，React 会复用之前的 WorkInProgress Tree！

假设第一次渲染还在构建第 10 层节点，第二次点击来了。React 不需要从头开始，它可以直接复用第一次渲染已经构建好的第 1 到 9 层节点，只从第 10 层开始重新构建。

这全靠 alternate 的引用传递。旧的 WorkInProgress 节点被标记为 alternate，新的节点复用了这些对象。React 通过标记 alternate 的 effectTag，知道哪些节点需要被丢弃，哪些需要被更新。

这就像你在画一幅画，虽然画被擦掉了重画，但你画过的底稿（已经确定的部分）还在，你只需要在空白处接着画就行了。

---

第七部分：总结与展望

好了，各位听众，我们的讲座接近尾声。让我们回顾一下今天这个“时间旅行者”——alternate 指针。

1. 身份识别： 它是新旧 Fiber 节点之间的身份证明。
2. 复用的基石： 没有它，React 每次渲染都要销毁重建整个 DOM 树，性能会慢得像蜗牛。
3. 内存的魔法： 它允许 React 在不复制整个树的情况下，构建新树。
4. 协调的桥梁： 它帮助 Diff 算法识别节点是移动了、删除了还是新增了。

React 的架构设计之所以优雅，很大程度上归功于这种“指针式”的复用策略。它不追求表面的“快”（比如暴力重绘），而是追求底层的“省”（省内存、省计算）。

最后，我想送给各位一句 React 源码里的名言，也是对 alternate 策略最好的注解：

“We don’t create new nodes. We reuse old ones. We just change their clothes.”

（我们并不创造新节点。我们复用旧的。我们只是换上了新衣服。）

当你下次在控制台里看到那些千奇百怪的 alternate 属性时，不要觉得它奇怪。你应该感到敬畏。因为那不仅仅是一个指针，那是 React 为了给你提供丝滑的 60fps 体验，在幕后默默付出的所有努力。

这就是 React Fiber 的秘密。现在，去写代码吧，让你的组件树更加高效！谢谢大家！