嘿，各位前端界的“代码炼金术士”们，大家好！
欢迎来到今天的深度解剖课。今天我们要聊的东西有点“硬核”，有点“烧脑”，但绝对能让你在写代码时，看着屏幕上的 React 渲染过程，内心涌起一种“上帝俯瞰众生”的快感。
我们今天的主题是：React 挂载阶段的原子性保证：探究 commitRoot 阶段如何利用单线程特性实现 DOM 更新的同步性。
别被这个标题吓到了。简单来说，我们要解决的问题是：为什么当你点击一个按钮，React 不会先画个一半的按钮，再画另一半？为什么你的 DOM 树永远不会处于一种“半死不活”的中间状态？
这就涉及到 React 的“原子性”概念，以及它如何利用 JavaScript 的“单线程”特性来耍这个魔术。
准备好了吗？让我们把咖啡机打开，把大脑预热，我们要开始“拆解” React 了。
第一章：单线程的独裁统治
首先，我们要明白一个最基础，也是最根本的事实：JavaScript 是单线程的。
这就像是一个只有一把刀的厨房。厨师（主线程）一次只能做一件事。你不能让他在切菜的同时炒菜，也不能让他在洗菜的时候切肉。如果他切菜切到一半，突然跑去洗菜，那么盘子里的菜就会变得乱七八糟，甚至切到手指。
在 React 的世界里，浏览器只有一个主线程。这个线程负责解析 JS，执行 DOM 操作，计算样式，绘制像素。它就像一个暴君，它不允许并发，它不允许“半成品”。
如果 React 允许并发——也就是允许你切菜切一半，暂停一下，去洗个菜，然后再回来切——那么当你再次回来的时候，你可能会发现，你切了一半的菜已经被别人弄乱了，或者你刚才切的部分和后面洗菜的部分混在了一起。
这就是“原子性”的来源。
原子性意味着：要么全部成功，要么全部失败（或者更准确地说，要么全部完成，要么根本不开始）。 在 React 的挂载阶段，这种原子性是通过 commitRoot 阶段的同步执行来保证的。
第二章：Fiber 架构的调度与执行
在进入 commitRoot 之前，React 其实已经忙活了半天。它经历了 render 阶段，也就是“思考阶段”。在这个阶段，React 会遍历你的组件树，计算哪些节点需要创建，哪些需要更新，哪些需要删除。它就像一个建筑设计师，在纸上画好了所有的蓝图，甚至算好了砖头和水泥的用量。
这个阶段是异步的（大部分情况下），因为它可以利用浏览器的空闲时间，比如当你滚动页面的时候，React 在后台偷偷计算下一帧的渲染。
但是，光有蓝图是不够的，得盖房子啊！commitRoot 就是那个“盖房子”的阶段。
在这个阶段，React 会拿走设计师画好的蓝图，开始真正的 DOM 操作。因为 JavaScript 是单线程的，所以这个阶段必须是同步的。一旦开始，就不允许被打断，直到所有的 DOM 更新都完成。
第三章：commitRoot 的核心逻辑
让我们直接看源码（当然是经过高度抽象和美化的版本）。commitRoot 的核心逻辑大概是这样的：
// 这是一个高度简化的 commitRoot 内部逻辑
function commitRoot(root) {
// 1. 检查是否有错误，如果有错误，直接抛出，整个提交过程回滚（虽然 React 现在的机制更复杂，但概念类似）
if (root.pendingCommitExpirationTime > 0) {
// 2. 获取需要提交的 fiber 节点列表
const effects = getPendingEffects(root.current);
// 3. 开始同步执行 DOM 更新
// 注意：这是一个同步的 for 循环，没有 await，没有 Promise.then
for (let i = 0; i < effects.length; i++) {
const fiber = effects[i];
// 根据不同的 effectTag 执行不同的操作
switch (fiber.effectTag) {
case Placement:
commitPlacement(fiber); // 插入 DOM
break;
case Update:
commitWork(fiber); // 更新 DOM
break;
case Deletion:
commitDeletion(fiber); // 删除 DOM
break;
}
}
// 4. 提交完成，清空副作用列表，通知 React 渲染完成
root.current.effectTag = NoEffect;
root.pendingCommitExpirationTime = NoExpiration;
// 5. 执行副作用回调（useLayoutEffect 和 useEffect）
commitLayoutEffects(root.current);
}
}看到了吗？关键在于那个 for 循环。这个循环是同步的。在浏览器渲染管线中，requestAnimationFrame 之前，主线程是空闲的。React 就是在这个空档期，像一台不知疲倦的打印机一样，把所有的 DOM 变更一次性“吐”出来。
第四章：DOM 变更的原子性实现
现在，让我们深入看看 commitPlacement、commitWork 和 commitDeletion。这些函数负责真正的 DOM 操作。React 不会对每个节点单独调用 document.createElement，那样太慢了，而且会导致大量的浏览器重排。
相反，React 会进行批处理。
假设你的组件树结构是这样的：
function App() {
return (
<div className="container">
<header>我是头部</header>
<main>
<p>我是正文</p>
<button>我是按钮</button>
</main>
</div>
);
}当你第一次挂载这个组件时，React 的 Fiber 树会生成一个副作用列表（Effect List）。这个列表的顺序非常讲究，它通常遵循后序遍历的规则。
为什么是后序遍历？
因为子节点必须先于父节点提交。你不能在父 <div> 插入之前，就把子 <p> 插入进去。这就像盖楼，必须先打地基（子节点），再砌墙（父节点），最后封顶（根节点）。
React 的 commitPlacement 函数会利用这个顺序，通过 parent.appendChild(child) 来插入节点。
代码示例：模拟 commitPlacement
function commitPlacement(fiber) {
// 找到父节点
const parentFiber = fiber.return;
const parentDOM = parentFiber.stateNode;
// 找到要插入的节点（这里简化了 DOM 节点的查找过程，实际 React 会缓存 DOM 引用）
const nextFiber = fiber;
// 执行插入操作
// 注意：这是一个同步的、原子的操作
if (fiber.effectTag === Placement) {
// 获取真实的 DOM 节点
const domNode = fiber.stateNode;
// 将 DOM 节点插入到父节点的子节点列表中
parentDOM.appendChild(domNode);
// 清除标记，表示这个节点已经提交完成了
fiber.effectTag &= ~Placement;
}
}在这个过程中，如果 appendChild 抛出了一个异常（比如内存不足，或者节点已经被移除了），那么整个 commitRoot 函数就会抛出异常。React 的错误边界机制会捕获这个异常，防止页面崩溃，但这仍然保证了在异常发生之前，之前的所有 DOM 更新都已经生效了。一旦发生异常，React 会回滚到上一次的有效状态。
第五章：useLayoutEffect 与 useEffect 的同步性
你可能会问：“等等，你说 DOM 更新是同步的，那我的 useEffect 呢？useEffect 不是异步的吗？”
好问题！这触及到了 React 原子性保证的另一个层面。
React 将副作用分为了两类：
- Layout Effects（布局副作用）： 对应
useLayoutEffect。它们在 DOM 更新之后、浏览器绘制之前执行。因为它们在同一个同步调用栈中，所以它们可以读取最新的 DOM 状态，甚至修改 DOM（虽然不推荐）。 - Passive Effects（被动副作用）： 对应
useEffect。它们在浏览器完成绘制之后执行。
让我们看看 commitLayoutEffects 是怎么做的：
function commitLayoutEffects(fiber) {
// 遍历 effect list
while (fiber !== null) {
switch (fiber.effectTag) {
case Update:
// 更新 DOM...
commitWork(fiber);
break;
case Placement:
// 插入 DOM...
commitPlacement(fiber);
break;
case PlacementAndUpdate:
// 先插入，再更新...
commitPlacement(fiber);
commitWork(fiber);
break;
// 处理 useLayoutEffect
case HookInsertion:
case HookLayout:
commitLayoutEffect(fiber);
break;
}
fiber = fiber.nextEffect;
}
}React 会先完成所有的 DOM 变更（Mutation 阶段），然后立即执行所有的 useLayoutEffect。这保证了 useLayoutEffect 中的代码看到的 DOM 是最新的，而且它不会阻塞浏览器的下一次绘制，因为它在绘制之前就跑完了。
至于 useEffect，它会在 Mutation 阶段之后，Layout 阶段之后，等待浏览器完成第一帧的绘制。这时候，React 会把 useEffect 的回调放入一个宏任务队列中。因为主线程在 commitRoot 之后已经完成了所有同步工作，所以 useEffect 的执行是异步的，但它不会破坏 DOM 更新的原子性，因为 DOM 已经是最终状态了。
第六章：为什么不能是异步的？
你可能会想：“React 的渲染阶段是异步的，为什么提交阶段不能也是异步的？万一我在提交过程中用户点击了按钮怎么办？”
这是一个非常深刻的架构问题。
如果 commitRoot 是异步的，那么在 DOM 更新完成之前，浏览器会渲染一个“中间状态”。比如，一个列表正在加载，你看到第一项已经显示出来了，但第二项还是空的，第三项还在闪烁。这种“残缺”的 UI 会让用户感到困惑，甚至可能导致数据不一致。
原子性保证了视觉上的连续性。
想象一下你在玩拼图。如果你拼到一半，突然把拼图收起来，明天再拼，你肯定拼不回去了。React 的 commitRoot 就是那个“一旦开始，必须完成”的过程。它把 DOM 的更新变成了一笔“原子交易”。
第七章：性能的权衡
当然，这种原子性保证是有代价的。因为 commitRoot 是同步的，如果组件树非常庞大，或者 DOM 操作非常复杂，那么 commitRoot 可能会阻塞主线程。
这就解释了为什么 React 团队要引入并发渲染（Concurrent Rendering）。并发渲染并不是要改变 commitRoot 的原子性，而是要优化 render 阶段的计算速度。
在并发模式下，React 可以在 commitRoot 开始之前，如果发现主线程比较空闲，就可以提前开始下一帧的渲染计算。但是，一旦 commitRoot 开始执行，它就必须全速运行，直到完成。
这就像一个快递员。他在路上（render 阶段）可以慢慢走，看看风景，甚至停下来休息一下。但是一旦他到了收件点（commitRoot），他就必须迅速、准确地完成派送，不能把包裹扔在门口就走，也不能只送一半。
第八章：实战中的原子性感知
在实际开发中，我们如何感知这种原子性？
最典型的例子就是 CSS 动画。
如果你在 useEffect 里添加一个 CSS 类来触发动画，你会发现动画是从头开始播放的，而不是从中间开始。这是因为 React 先完成了 DOM 的更新，然后才触发 useEffect。DOM 的更新是原子的，所以动画也是从初始状态开始的。
但是，如果你在 useLayoutEffect 里操作 DOM，比如修改 element.style.width，你会发现这种修改是瞬间的，用户看不到变化的过程。这也是因为 useLayoutEffect 在浏览器绘制之前执行，而且它是同步的。
第九章：深入 Effect List 的构建
为了真正理解原子性，我们必须理解 Effect List 的构建。Effect List 是一个链表，它记录了所有需要执行的 DOM 操作。
React 会遍历 Fiber 树，根据节点的 effectTag 来决定是否将其加入 Effect List。这个过程是在 render 阶段完成的。
function reconcileChildren(current, workInProgress, nextChildren) {
let result = createChildren();
// 遍历子节点
for (let i = 0; i < nextChildren.length; i++) {
const child = nextChildren[i];
// ...
if (child !== null) {
// 如果是新节点，标记为 Placement
if (workInProgress.child === null) {
workInProgress.effectTag |= Placement;
}
// 递归处理子节点
reconcileChildren(null, workInProgress.child, child);
}
}
return result;
}注意这里的递归。React 是从根节点开始，递归到最底层的叶子节点，然后再从叶子节点返回到根节点。这种后序遍历的顺序，决定了 Effect List 的顺序。
当 commitRoot 执行时，它会按照这个顺序，从叶子节点到根节点，依次执行 DOM 操作。这就像是在给一棵树浇水，你必须先浇最底下的叶子，才能浇树干。
第十章：单线程的“并发”错觉
虽然 JavaScript 是单线程的，但 React 通过 requestIdleCallback 和 requestAnimationFrame 模拟了并发。
requestIdleCallback 会在主线程空闲时调用，React 利用它来执行 render 阶段的工作。requestAnimationFrame 会在浏览器准备绘制下一帧时调用，React 利用它来触发 commitRoot。
但是，commitRoot 本身并不是通过 requestIdleCallback 调用的。它是通过 requestAnimationFrame 的回调函数直接调用的。这意味着 commitRoot 是在浏览器的“渲染周期”中执行的。
在每一帧中，浏览器的工作流程大致如下：
- 输入处理： 处理用户输入。
- 脚本执行： 执行 JavaScript 代码。
- 样式计算： 计算 CSS。
- 布局： 计算布局。
- 绘制： 绘制像素。
- 合成： 合成图层。
React 的 commitRoot 发生在脚本执行阶段，在布局和绘制之前。这保证了 DOM 的更新是同步的，而且不会影响浏览器的渲染性能。
第十一章：错误边界与原子性的回滚
如果 commitRoot 过程中发生错误怎么办？
React 的错误边界机制可以捕获组件树中的错误，防止整个应用崩溃。但是，如果错误发生在 commitRoot 阶段，React 会怎么做呢？
React 会尝试回滚 DOM 状态。它会执行 commitDeletion，移除所有新创建的节点，并恢复到上一次的有效状态。这个过程是自动的，对用户是不可见的。
这进一步强化了原子性的概念：Commit 阶段是一个不可分割的整体。如果其中一部分失败了，那么整个部分都会失败。
第十二章：总结（不，我们不总结）
好了，各位，我们讲了这么多。我们探讨了单线程的特性如何赋予了 React 原子性的保证。我们剖析了 commitRoot 的执行流程，我们分析了 Effect List 的构建顺序，我们讨论了 useLayoutEffect 和 useEffect 的区别。
React 的原子性保证，本质上是对 JavaScript 单线程特性的极致利用。它通过同步的 commitRoot 阶段，将 DOM 的更新变成了一笔不可分割的交易。
这种机制虽然牺牲了一些性能（在极端情况下可能会阻塞主线程），但它带来了巨大的好处：视觉上的连贯性。用户永远不会看到半成品，永远不会看到数据不一致的界面。
这就是 React 的魔法，这就是为什么 React 如此受欢迎。它不仅仅是代码库，它是一套精妙的设计哲学。
现在，闭上眼睛，想象一下你的 React 应用。当数据变化时，React 并不是在乱涂乱画，而是在进行一场精密的手术。它从根节点开始，一层层地深入，然后一层层地完成。所有的 DOM 更新都是同步的，都是原子的。
当你下次看到 React 的渲染过程时，希望你能想起今天讲的这些内容。你会看到那些 Fiber 节点在 Effect List 中排队，你会看到 commitRoot 函数在主线程上飞快地执行，你会看到 DOM 节点一个个地被创建、更新、删除。
这就是 React，这就是前端开发的魅力。
好了，今天的讲座就到这里。我要去写代码了，毕竟，代码是不会骗人的，只有人会骗人。祝大家编码愉快，原子性满满！
（完）