大家好，我是你们的 React 架构师，或者你可以叫我“内存管理大师”。
今天我们不聊怎么写 useEffect，也不聊怎么调优组件性能，我们要聊聊一个更底层、更硬核、甚至有点“变态”的话题：垃圾回收。
你有没有想过，为什么 React 渲染得那么快，却不像 Vue 那样频繁触发 GC（Garbage Collection）？当你在点击按钮时，React 没有像传统的 Web 框架那样，每次渲染都把旧的虚拟 DOM 删得一干二净，然后重新创建一堆新对象，对吧？如果你那样做，你的内存分配器会疯掉的，浏览器会卡成 PPT。
React 的秘密武器，就是这个被藏在源码深处、冷门却至关重要的属性——alternate。
很多人知道 Fiber 架构，知道时间切片，但很少有人真正理解 Fiber 节点复用机制。今天，我们就来扒开 React 的裤衩（比喻），看看它是如何通过 alternate 这个机制，在内存的刀尖上跳舞，精确复用旧 Fiber 内存块，以此来抑制那该死的 GC 抖动。
准备好了吗？我们要开始“硬核”了。
第 1 节：内存的噩梦与“备胎”哲学
首先，我们要建立一个共识：在 JavaScript 的世界里，创建对象就是往堆内存里扔砖头。如果你每次渲染都扔几十万块砖头，垃圾回收器（GC）就会在那儿不停地大喊：“卧槽！新砖头！卧槽！旧砖头！快收！快收！”
这就是 GC 抖动。GC 一旦开始工作，线程就会暂停，页面就会卡顿。用户就会看到那个令人心碎的转圈圈。
React 作为一个高性能框架，它的目标只有一个：尽量让 GC 闭嘴。
怎么闭嘴？答案是：别销毁旧对象，除非万不得已。
这就好比你去餐厅吃饭。
- 传统做法：吃完一餐，把桌椅都拆了，换成新的，把盘子全摔了，换个新的盘子。虽然看起来干净，但搬家太累了，而且还要花钱买新盘子。
- React 做法：吃完一餐，你不拆桌子，也不换盘子，只是在盘子上刷一层蜡（更新 props），然后继续用这张桌子。等你需要腾地儿的时候（提交阶段），再把旧桌子换出去。
在这个过程中，Fiber 节点就是那张桌子。
为了实现这个“不换桌子”的策略，React 为每个 Fiber 节点引入了一个属性，名字很普通，叫 alternate。它的中文意思大家都知道——备胎、替补。
这可不是随便叫的。在 Fiber 的世界里，每一个节点都有可能成为“备胎”。
第 2 节：Fiber 的双胞胎兄弟
让我们来看看 Fiber 节点的标准定义（简化版）：
class FiberNode {
// 节点的基本信息
type: any; // 组件类型（函数、类、DOM标签）
key: string | null; // 用来区分列表中不同节点的 Key
props: any; // 传给组件的 props
stateNode: any; // DOM 节点实例或 Context 对象
// ！！！核心属性！！！
// 指向当前渲染树上该节点的“另一个版本”
alternate: FiberNode | null;
// 指向父节点
return: FiberNode | null;
// 指向子节点
child: FiberNode | null;
// 指向兄弟节点
sibling: FiberNode | null;
}注意看 alternate。在 React 的并发模式（Concurrent Mode）下，这个属性是复用机制的灵魂。
第 3 节：挂载 vs. 更新——alternate 的两种生法
Fiber 节点的生命周期分为两个截然不同的阶段：挂载 和 更新。alternate 在这两个阶段的表现完全不同。
场景 A：初次渲染
假设你有这样一个组件树：
function App() {
return <div><h1>Hello World</h1></div>;
}当 React 第一次渲染这个 App 时，它在内存里会造出这么一棵树：
- Root Fiber:
alternate = null。它是个单身汉，没有过去。 - Div Fiber:
alternate = null。也是个单身汉。 - H1 Fiber:
alternate = null。依然是单身汉。
注意，这里全是 null。因为这是第一次，没有旧版本，没有“备胎”，React 只能老老实实 new FiberNode()，从头造。
场景 B：并发更新
现在，你点击了一个按钮，App 组件重新渲染了。注意，这次是并发渲染。React 并没有直接把旧树砸了重建，而是启动了第二个线程（在宏观线程中是协作式的）来构建一棵新的树。
这棵新树叫 workInProgress（工作中的树）。
这时候，神奇的 alternate 机制上线了。
React 在构建 workInProgress 树的时候，它会像扫描仪一样扫描旧的树（current 树）。如果发现一个节点的类型和 Key 没变，React 会做一件极低成本的事情：
复用对象！
代码逻辑大概长这样（伪代码）：
// 伪代码演示 React 内部逻辑
function reconcileChildren(currentFiber, newChildren) {
// 我们正在构建 workInProgress 树
// 遍历新子节点
for (let i = 0; i < newChildren.length; i++) {
let newFiber = createFiber(newChildren[i].type, newChildren[i].key);
if (currentFiber) {
// 关键点来了：如果旧节点存在，我们把旧节点挂到新节点的 alternate 属性上
newFiber.alternate = currentFiber;
// 并且把新节点挂到旧节点的 alternate 属性上
currentFiber.alternate = newFiber;
} else {
// 如果是首次渲染，alternate 就是 null
newFiber.alternate = null;
}
// ... 继续构建 nextSibling 等
}
}看懂了吗？
当 React 构建新树时，它并不是真的 new FiberNode()。它只是找出了对应的旧 Fiber 节点，把它的地址赋给了 newFiber.alternate。
此时，内存里有两棵树在运行，但是它们共享着底层的 FiberNode 实例！旧节点还在那儿，没有变成垃圾。
第 4 节：属性的深度复制与内存优化
也许你会问：“嘿，大师，虽然节点复用了，但 props 变了啊！比如 className 从 foo 变成了 bar。如果复用了节点，是不是要把旧 props 里的 className: 'foo' 擦掉，再写 className: 'bar'？”
是的，React 在 completeWork 阶段确实会做这个操作。但是，这里有一个巨大的性能陷阱。
如果 React 每次都 delete oldProp 然后 assign newProp，这就是在修改对象。虽然 JS 引擎有优化，但在极端并发情况下，频繁修改对象属性会导致对象碎片化，进而诱发 GC。
React 的策略是：在 workInProgress 树中，我们只更新变动的属性，但保留未变动的属性。
更重要的是，在提交阶段（Commit）之前，React 还会做一个骚操作：将 current 树上节点的 props，直接复制给 workInProgress 树上对应节点的 alternate（也就是旧节点）。
这意味着什么？意味着如果 App 组件重新渲染，而 h1 标签的 title 属性没变，React 甚至连 h1 的 props 对象都不用新建！它直接把旧 props 对象的引用，塞进了新 props 对象里。
// 伪代码：completeWork 阶段的优化
function completeWork(current, workInProgress) {
// 如果 current 存在（说明是更新），且类型匹配
if (current && workInProgress.type === current.type) {
// 1. 复制 props
// 这是一个浅拷贝，但利用了引用特性
// 比如: current.props.className = 'foo'; workInProgress.props.className = 'bar';
// 旧的 'foo' 其实还在内存里，只是没人引用它了（或者被标记为即将回收）
workInProgress.props = { ...current.props, ...workInProgress.pendingProps };
// 2. 这才是重头戏
// React 会把当前节点（新树里的节点）的 alternate 属性（也就是旧节点）更新一下
// 这样，旧节点就变成了“新版本”，下次渲染时，它又能作为备胎被复用
workInProgress.alternate.props = workInProgress.props;
workInProgress.alternate.stateNode = workInProgress.stateNode;
}
}这就是为什么 React 不会频繁 GC。它通过 alternate 链条，把旧节点变成新节点，把新节点变成旧节点。内存对象的生命周期被无限拉长了！
第 5 节：代码演示——手写一个“反 GC”渲染器
为了让你彻底理解，我们抛弃复杂的 React 源码，用几行代码写一个迷你渲染器，模拟这个机制。
// 1. 定义 Fiber 节点类
class FiberNode {
constructor(type, key, props) {
this.type = type;
this.key = key;
this.props = props;
this.alternate = null; // 默认没有备胎
this.child = null;
this.sibling = null;
}
}
// 2. 模拟 React 的渲染函数
function render(newVdom, parentNode) {
// 这是一个模拟的全局状态，记录当前根节点的 current Fiber
let rootFiber = currentRootFiber;
// 3. 核心逻辑：创建新树
// 假设我们有一个虚拟 DOM 树对象 newVdom
// 我们遍历它，创建对应的 Fiber 节点
const workInProgressFiber = createFiberFromVNode(newVdom, rootFiber);
// 4. 赋值 Alternate
// 如果有旧根节点，建立联系
if (rootFiber) {
rootFiber.alternate = workInProgressFiber;
workInProgressFiber.alternate = rootFiber;
}
// 5. 更新全局状态
currentRootFiber = workInProgressFiber;
// 6. 提交（简化版：直接把 DOM 扔进页面）
commit(workInProgressFiber, parentNode);
}
// 辅助函数：从虚拟 DOM 创建 Fiber
function createFiberFromVNode(vnode, alternate) {
const fiber = new FiberNode(vnode.type, vnode.key, vnode.props);
// 关键点：如果传了 alternate，说明是复用
if (alternate) {
fiber.alternate = alternate;
alternate.alternate = fiber;
}
return fiber;
}
// 模拟 GC 抖动测试
const container = document.getElementById('root');
let currentRootFiber = null; // 初始为空
// 第一次渲染
const vDom1 = { type: 'div', props: { id: 'old-div', text: 'Old Text' } };
render(vDom1, container);
console.log("第一次渲染完成");
// 第二次渲染（属性变了，但节点类型没变）
const vDom2 = { type: 'div', props: { id: 'new-div', text: 'New Text' } };
render(vDom2, container);
console.log("第二次渲染完成");
// 检查内存复用情况
// 由于我们简化了代码，这里只是逻辑演示。
// 在真实 React 中，你会发现两次渲染后，内存里大概率还是那个 FiberNode 对象，
// 只是它的 props 被修改了，或者它的 alternate 指针被更新了。上面的代码非常短，但包含了核心逻辑。看不懂也没关系，我们来解释一下它的“恐怖”之处。
在 render 函数的第四步，rootFiber.alternate = workInProgressFiber。这行代码执行后，内存结构变成了这样：
[Old Root Fiber]
|
+---- alternate: [New Root Fiber]
|
+---- (其他属性)
[New Root Fiber]
|
+---- alternate: [Old Root Fiber]
|
+---- (其他属性)React 的 currentRootFiber 指向 [Old Root Fiber]（这是浏览器现在正在看的树）。而 workInProgressRootFiber 指向 [New Root Fiber]（这是 React 正在构建的树）。
下一次渲染时，React 会发现 currentRootFiber 存在，于是它会把 [New Root Fiber] 当作 alternate，把 [Old Root Fiber] 当作 current。
于是，链路就转起来了。这就是传说中的 Fork and Merge。
第 6 节：为什么这能抑制 GC？
我们来算一笔账。
没有 alternate 的世界（传统方式）：
- Mount: 分配 Node A, Node B, Node C。（分配内存）
- Update: 销毁 Node A, B, C。（GC 工作）
- Update: 分配 Node A’, B’, C’。（分配内存）
- Update: 销毁 Node A’, B’, C’。（GC 工作）
- Update: 分配 Node A”, B”, C”。（分配内存）
… GC 像是一个不知疲倦的清洁工，每隔几毫秒就要来大扫除一次。
有 alternate 的世界（React 方式）：
- Mount: 分配 Node A, B, C。
alternate = null。 - Update: Node A’ 找到 Node A，设置
A'.alternate = A，A.alternate = A'。没有分配新内存！ - Update: Node A” 找到 Node A’，设置
A''.alternate = A'，A'.alternate = A''。依然没有分配新内存！ - Commit: 交换指针。Node A’ 变成了 current，Node A 变成了 alternate（虽然被 GC 收走了，但这是一次性的）。
结论：
在两次渲染之间，Fiber 节点的实例对象（包含 type, key, stateNode 等开销大的属性）完全没有被销毁和重建。它们一直躺在内存里，处于“待机”状态。
只有当组件卸载，或者结构发生剧烈变化（Key 不匹配，导致 React 无法复用节点）时，那些 Fiber 节点才会被真正销毁。
这就是 React 抑制 GC 抖动的终极奥义：保持对象存活，通过引用复用来减少内存分配的峰值。
第 7 节：Key 的悲剧——什么时候会破坏复用？
既然 alternate 如此强大，那为什么我们写列表时还要写 key？
因为 alternate 机制是建立在同类型节点之上的。
假设你有一个列表：
<ul>
<li key="1">Item 1</li>
<li key="2">Item 2</li>
<li key="3">Item 3</li>
</ul>当列表变成：
<ul>
<li key="1">Item 1 (Updated)</li>
<li key="4">Item 4 (New)</li>
<li key="2">Item 2 (Moved)</li>
</ul>React 在构建新树时，发现 key="2" 的节点跑到最后面去了。React 的协调算法发现，虽然类型都是 li，但位置变了。它无法简单地复用原来的 FiberNode。
为了性能（以及保持父子引用的正确性），React 会丢弃原来的 FiberNode，创建一个新的 FiberNode。
这时候，GC 就会介入了。
所以，key 的作用不仅仅是优化 Diff 算法的速度，它也是告诉 React：“嘿，这个 DOM 元素很重要，请务必复用这个 Fiber 节点，别给我 GC 掉！”
第 8 节：总结与实战建议
好了，讲到这里，我们基本上摸到了 React 内部内存管理的精髓。
alternate 机制就像是 React 的记忆海绵。它记住了上一帧的画面，当新画面来临时，它试图在旧画面的基础上进行修改，而不是扔掉画布重画。
给开发者的建议：
- 善用 Key：这是最直接的贡献。如果你不写 Key，React 就无法复用 Fiber 节点，每次渲染都会触发大量对象创建，GC 就会嗡嗡作响。
- 理解 Fiber：虽然你不需要手动操作
alternate，但理解它有助于你理解 React 的渲染周期。 - 避免不必要的重渲染：如果你把一个组件的 Key 设为
index，当列表顺序改变时，React 就会认为这是三个不同的节点，从而销毁并重建它们。这会触发大量的内存分配和 GC。
终极奥义：
React 的高性能不仅仅来自于 Diff 算法的精妙，更来自于对内存分配的极致控制。alternate 属性是这种控制的核心枢纽。它让 React 能够在“并发渲染”的混乱中，依然保持对内存的绝对统治力。
这就是为什么你在编写高性能 React 应用时，很少会看到内存占用随着页面运行时间增加而无限制飙升的原因。React 就像一位精打细算的管家，用最少的资源，干最漂亮的事。
好了，今天的讲座就到这里。现在，去检查一下你的代码里，是不是忘了写 key 吧！