好，坐好，拿好笔记本。别急着把“React 高级源码”这五个字从脑子里划掉，我知道你现在想找“快速上手”或者“生命周期避坑指南”。但这篇文章，我们不讲那些鸡毛蒜皮，我们讲的是 React 的核子物理学。
你有没有想过，当你点击一个按钮，React 仅仅用了几毫秒就更新了屏幕，它到底干了什么？它是把旧的那棵树一把火烧了，重新种了一棵新的吗？如果是，那你手机里的浏览器早就在内存溢出中崩了。
今天我们要聊的，是 React 的灵魂——双缓存架构。特别是重点，重点中的重点：在 Commit 阶段，那两棵树——Current 树和 WorkInProgress 树——是如何通过物理指针的交换，完成一场惊心动魄的“变脸”魔术的。
别被这名字吓到，这其实就是个接力赛，只不过跑的是内存指针。
第一部分：为什么我们需要“双缓冲”？（别拿内存开玩笑）
先说个不恰当的比喻，你装修房子。你现在住在这个房间里（Current 树）。你想把墙刷成新的颜色（更新 DOM）。你总不能站在油漆桶里刷墙吧？那不现实，而且你会把油漆弄得到处都是，甚至掉到你的睡袋里。
所以，聪明的做法是什么？你在隔壁搭个棚子（WorkInProgress 树）。你在棚子里把墙刷好，摆好家具，把地板铺好。这一步在内存里进行，谁也看不见。
当你觉得完美了，啪！一脚踹开那扇破门，直接住进新棚子（Commit 阶段）。
这时候，旧棚子怎么办？没人要了？扔了？那不行，扔了要收垃圾费，而且如果你突然觉得新棚子不行，想回旧棚子住，还得重新搭。太麻烦了。
React 的双缓存，就是为了解决这个“搭棚子”的问题。
在 React 的世界里：
- Current 树：当前渲染在屏幕上的那棵树。用户看到的，摸到的，是它。
- WorkInProgress 树：正在后台构建的树。它是下一帧的预演。
第二部分：Fiber 节点——单细胞生物的链表
要理解指针切换，你得先理解 React 树长什么样。它不再是简单的递归调用栈了（那是老黄历了），它是 Fiber 架构。
你可以把每一个 React 组件看作一个 Fiber 节点。这可不是个普通的节点，它是个多面手，集导演、演员、道具师于一身。
class FiberNode {
constructor(tag, pendingProps, key, mode) {
// 身份证信息
this.tag = tag; // 组件类型：FunctionComponent, ClassComponent 等
this.key = key;
this.type = null;
// 这里的 props 是即将要用的，而不是已经用的
this.pendingProps = pendingProps;
this.memoizedProps = null;
this.memoizedState = null;
// --- 核心结构：链表 ---
this.return = null; // 父节点（类似 return 语句）
this.child = null; // 第一个子节点
this.sibling = null; // 下一个兄弟节点（类似 for 循环中的 next）
// --- 双缓冲的秘密 ---
this.alternate = null; // 这是关键！它指向同一类型树的另一棵
}
}注意看 this.alternate。这就像你左手拿的一只手套，右手拿的一只手套。它们是同一个型号，但不是同一只。React 不会帮你克隆整个树，而是利用这个 alternate 属性来回跳跃。
第三部分：Commit 阶段——指针的华尔兹
好了，理论铺垫完毕。现在到了最刺激的部分：Commit 阶段。
Commit 阶段发生在一个叫 commitRoot 的函数里。这个时候，workInProgress 树已经渲染完成了。接下来，React 需要把这棵“新棚子”变成现实。
在这个阶段，最核心的操作就是 指针交换。
1. 初始状态
想象一下，屏幕上有一棵树，根节点叫 rootFiber。
rootFiber 是 Current 树的根。
它的 alternate 属性指向了另一棵树，这棵树我们叫它 oldWorkInProgress（其实这就是上一帧的 Current 树，稍后我会解释为什么这么叫）。
2. 渲染阶段
React 开始调度。它在内存里疯狂运算，构建出了新的一棵树。这棵树的根节点叫 nextRoot。
此时，nextRoot 是 WorkInProgress 树的根。
在构建过程中，React 会非常勤快地给每个新节点赋值 alternate：
// 在 React 内部逻辑中，大概是这么干的
nextRoot.alternate = rootFiber; // 新树的老祖宗指向旧的 Current 树
rootFiber.alternate = nextRoot; // 旧的 Current 树的备胎指向新树3. Commit 开始
现在，时间到了。用户卡顿了吗？没有。性能还好。React 说：“兄弟们，把活儿干完吧，切换舞台！”
这时候，在源码里，会有一行惊天地泣鬼神的代码，完成了物理指针的切换：
function commitRoot() {
// 假设 workInProgressRoot 就是 nextRoot
const root = workInProgressRoot;
// ----------------------------------------------------
// 魔法时刻：指针切换
// ----------------------------------------------------
// 第一步：把新的 Current 树挂载到 Root 上
root.current = workInProgressRoot;
// 第二步：把旧的 Current 树赋值给 workInProgressRoot
// 注意！这里 workInProgressRoot 现在指向了旧的树
workInProgressRoot = root.current.alternate;
// 第三步：把 workInProgressRoot 的 alternate 指向 null
// 为什么？因为新树的构建任务完成了，它不需要再找另一个备胎了
workInProgressRoot.alternate = null;
// ----------------------------------------------------
// 此时，DOM 更新开始...
commitAllHostEffects(workInProgressRoot);
}4. 这一步到底干了啥？（深度解析）
来，我们拿显微镜看看这行代码 root.current = workInProgressRoot;。
- Before:
root.current指向的是TreeA（屏幕上的树）。workInProgressRoot指向的是TreeB（新构建的树）。 - Action:
root.current指针被拉向了TreeB。
后果 A：用户看到新树了。
因为 React 渲染器读取 DOM 的时候，是基于 root.current 来走的。现在它指向了 TreeB，所以浏览器开始根据 TreeB 绘制 DOM。
后果 B：内存没释放。
你可能会问：“那 TreeA 呢？谁负责删除它？垃圾回收器不收它怎么办？”
别慌。看看那行代码 workInProgressRoot = root.current.alternate;。
因为 TreeA（也就是 root.current.alternate）在 Commit 之前，它的 alternate 属性指向了 TreeB。
所以，workInProgressRoot 现在指向了 TreeA。
虽然我们不再用 workInProgressRoot 来干活了，但是 TreeB 还在引用着 TreeA（通过 alternate）。
这就形成了一个闭环：
TreeB 的根节点引用着 TreeA。
TreeA 的根节点引用着 TreeB。
它们手拉手，谁也不松手。所以，内存垃圾回收器（GC）会想：“嗯？这俩对象互相引用着，看起来都有用，那就都留着吧。”
这完美地保护了旧树，直到下一次渲染。
第四部分：全代码模拟——一场指针的接力赛
为了让你彻底明白，我写了一段模拟代码。这代码不是 React 源码，但它用纯 JavaScript 模拟了双缓存的逻辑。
// 模拟 Fiber 节点
class FiberNode {
constructor(tag, props) {
this.tag = tag;
this.props = props;
this.children = []; // 简化版：用数组存子节点
this.alternate = null; // 备胎
}
// 为了方便打印，加个 toString
toString() {
return `Fiber[${this.tag}]`;
}
}
// 模拟 React 根实例
class ReactRoot {
constructor(current) {
this.current = current; // 核心指针：当前屏幕上显示的树
}
}
// 1. 初始化：屏幕上有一棵树
console.log("--- 初始状态 ---");
let oldTreeRoot = new FiberNode(1, { name: 'Root' });
// 老树的根，它的备胎指向 null（因为它是唯一的）
oldTreeRoot.alternate = null;
let rootInstance = new ReactRoot(oldTreeRoot);
console.log(`rootInstance.current 是: ${rootInstance.current}`); // 输出 Fiber[1]
console.log(`oldTreeRoot.alternate 是: ${oldTreeRoot.alternate}`); // 输出 null
// 2. 渲染阶段：构建新的一棵树
console.log("n--- 开始构建 WorkInProgress 树 ---");
// 假设我们构建了一个新树
let newTreeRoot = new FiberNode(2, { name: 'Root-Next' });
newTreeRoot.alternate = rootInstance.current; // 新树的备胎指向当前的根
rootInstance.current.alternate = newTreeRoot; // 旧树的备胎指向新树
// 模拟构建子节点
let child1 = new FiberNode(3, { name: 'Child-1' });
let child2 = new FiberNode(4, { name: 'Child-2' });
newTreeRoot.children = [child1, child2];
// 此时：新树构建完成，准备 Commit
console.log(`newTreeRoot.alternate 是: ${newTreeRoot.alternate}`); // 输出 Fiber[1] (旧树)
console.log(`newTreeRoot 是: ${newTreeRoot}`); // Fiber[2]
// 3. Commit 阶段：指针切换
console.log("n--- Commit 阶段：指针切换 ---");
// 执行双缓存核心逻辑
// A. 新树接管屏幕
rootInstance.current = newTreeRoot;
// B. WorkInProgress 指向旧树（作为垃圾回收的护身符）
// 此时 workInProgressRoot 变量指向了旧树
let workInProgressRoot = rootInstance.current.alternate;
// C. 斩断新树的备胎，防止内存泄漏（旧树会被引用，不需要断）
newTreeRoot.alternate = null;
// 验证结果
console.log(`rootInstance.current 是: ${rootInstance.current}`); // Fiber[2] (新树)
console.log(`rootInstance.current.alternate 是: ${rootInstance.current.alternate}`); // null
console.log(`workInProgressRoot 是: ${workInProgressRoot}`); // Fiber[1] (旧树)
console.log(`workInProgressRoot.alternate 是: ${workInProgressRoot.alternate}`); // Fiber[2] (新树)
console.log("n--- 此时内存状态 ---");
console.log("Fiber[1] (旧树) 被留在了内存中。");
console.log("Fiber[2] (新树) 指向了 Fiber[1]。");
console.log("只要 Fiber[2] 还在使用，Fiber[1] 就不会被 GC 回收。这叫“临时驻留”或“借用引用”。");运行结果解读
- 初始：只有旧树。
- 构建：新树诞生了。它记住了“我的老祖宗是旧树”。
- Commit 切换：
rootInstance.current抬头挺胸，变成了新树。workInProgressRoot顺手牵羊，拿走了旧树（因为新树引用着旧树）。- 关键点：旧树没有死。它虽然不再挂在
rootInstance.current下了，但它被workInProgressRoot（也就是下一个渲染周期）临时“借用”了。
第五部分：为什么不用“克隆”？
你可能会问：“专家，既然有新树了，直接把旧树删了，把新树复制一份变成 Current 树不就行了？”
不行，那是“深拷贝”。那是性能杀手。
React 的组件里有很多昂贵的计算，比如过滤一个巨大的数组。如果每次渲染都重新计算、重新创建对象，那页面就是一卡一卡的。
双缓存的精髓在于“复用”。
在 Commit 切换的那一瞬间，内存里只有两棵树，而不是三棵（旧树 + 新树 + 屏幕上的树）。
因为 workInProgress 指向了 current.alternate，所以旧树还在内存里。当 React 进入下一轮渲染（比如你点了另一个按钮）时，它会发现 root.current 指向的是 TreeB。它会去拿 TreeB.alternate，也就是 TreeA。
然后，React 会拿着 TreeA（这次变成了 WorkInProgress）去构建 TreeC。
你看，这就是接力棒！
A -> B
B -> C
C -> D
每一棒选手都利用上一棒选手的身体作为“备胎”或“借力点”，只需要稍微动一下手指（修改指针），或者稍微调整一下姿势（更新 props），就能跑出下一棒。这就是为什么 React 渲染如此丝滑的原因。
第六部分：物理指针切换的边界情况（Commit 阶段的副作用）
虽然指针切换很简单（就是赋值两个变量），但在 Commit 阶段，React 要干的可不只是换灯泡。
当指针切换完成（root.current = workInProgressRoot）之后，React 会遍历新树，去执行那些标记为 HasEffect（有副作用）的节点。
这就涉及到了你提到的 Commit 阶段。
- Before Commit: 屏幕上还是旧树。DOM 节点
div#app对应着旧树的根节点。 - 指针切换:
div#app的指针从旧树根节点变成了新树根节点。 - DOM Diff & Sync: React 比较新旧树的差异。
- 如果子节点没变：复用 DOM 节点（提高性能）。
- 如果子节点变了：删除旧 DOM，创建新 DOM。
这就好比那个“棚子”的比喻：
- 指针切换：你把旧棚子的牌子撕了，贴上了新棚子的牌子。
- DOM 同步：你把旧棚子里不需要的烂木头扔了，把新棚子需要的材料搬进来。
第七部分：如果不这样做会怎样？（单缓冲的悲剧）
让我们试想一个没有双缓冲的世界，或者 React 使用单缓冲（每次渲染完直接销毁旧树，重建新树）。
-
单缓冲：渲染新树 -> 销毁旧树内存 -> 同步 DOM。
- 问题：每次渲染都意味着大量的对象创建和销毁。JS 的垃圾回收器（GC）会非常痛苦。它会频繁地暂停主线程去清理内存，导致掉帧。
- 用户体验：页面像是在抽搐。
-
双缓冲：渲染新树 -> 保留旧树（通过指针引用） -> 同步 DOM。
- 优势：内存压力小。对象复用率高。
- 用户体验：页面如丝般顺滑。
第八部分：实战中的“指针”意识
当你在写自定义 Hook 或者理解 React 源码时，记住这个图景：
- Props Flow: 从
pendingProps到memoizedProps。这就像你手里拿着剧本（新 props），你要把它念给观众（DOM）听。 - Tree Switch: 从
current到workInProgress。这是导演换景。
workInProgress 就像是一个“半成品”的电影。它时刻准备着在下一帧变成正片。
总结一下（虽然我不写总结，但我必须点题）
这双缓存，其实就一句话：“旧的不去，新的不来；但旧的还在，只是换了把椅子坐。”
在 Commit 阶段，物理指针的切换是极其轻量级的操作。它没有深拷贝，没有递归遍历销毁，仅仅是改变了两个引用指向。这就像换灯泡一样，拧下来，拧上去，灯就亮了。而 React 实际去做的，是在那盏灯旁边重新装修房间（DOM Diff）。
所以，下次当你看到 React 的渲染日志，或者看到那一堆红红绿绿的 Fiber 节点时，别觉得它们乱七八糟。它们其实是在玩一场精密的接力赛。current 和 workInProgress 就是那两个交接棒的人，他们在 Commit 的那一瞬间，完成了一次无缝的、充满默契的物理交接。
这就是 React 的双缓存架构，优雅、高效，且充满逻辑美感。