各位同学，大家好！
欢迎来到今天的“React 源码深潜”特别讲座。我是你们的讲师，一个在代码海洋里摸爬滚打多年，深知“Fiber 架构”比“发际线”更难管理的资深工程师。
今天我们要聊的话题，是 React 渲染流程中那个“承上启下”的关键环节——completeWork。
很多人都知道 completeWork 是用来创建 DOM 节点的，就像装修队里的泥瓦匠，负责把砖头砌上去。但是，这只是冰山一角。在 React 的世界里，completeWork 更像是一个“管家”，或者一个“填表员”。它不仅要砌砖，还要在每一块砖（Fiber 节点）上贴上“标签”（Flags），告诉 Commit 阶段的工人：“嘿，这块砖是新来的，要插队；或者这块砖旧了，要翻新；或者这块砖搬家了，要扔掉！”
那么，除了把 DOM 节点抠出来，completeWork 还在幕后默默处理了哪些关于副作用标志的“冒泡”逻辑呢？今天我们就把这层窗户纸捅破。
准备好了吗？我们要开始扒开 React 的裤衩（不是，是源码）了。
第一部分：为什么要“冒泡”？—— 父与子的爱恨情仇
在深入代码之前，我们需要先理解一个哲学问题：为什么父节点需要知道子节点的副作用？
想象一下，你是一个 HTML 文档的“上帝”。你手里有一棵 Fiber 树。在 Render 阶段，你决定把一个 <div>（父节点）和里面的 <button>（子节点）都删了，换成 <p> 和 <span>。
在 Commit 阶段，浏览器需要执行 DOM 操作。浏览器不会说：“好的，我先删掉 div，再删掉 button。” 浏览器只会说：“好的，我要把当前的 DOM 树完全替换掉。”
这时候，React 需要告诉浏览器：“嘿，别傻傻地删了 div 再删 button，因为 div 下面挂着一堆子节点。你应该先处理子节点的变动，最后再处理父节点。”
这就好比你要搬家。你不能先把大箱子（父节点）扔在路边，再把小箱子（子节点）扔在路边。你必须先把小箱子放进车里，最后把大箱子搬上车。这就是副作用冒泡的核心逻辑。
在 completeWork 阶段，这个逻辑主要通过修改 workInProgress 节点的 flags 属性来实现。父节点的 flags 会携带子节点的变更信息。
第二部分：Placement（插入）的狂欢—— “我是新来的”
让我们直接切入源码。completeWork 的核心逻辑在 src/react-reconciler/completeWork.js 中。
首先，我们得知道，Fiber 节点有不同的类型。如果是 HostComponent（比如 div, span），那它对应的就是 DOM 节点。
function completeWork(
current: Fiber | null,
workInProgress: Fiber,
renderPriorityLevel: number,
): Fiber | null {
const nextChildren = workInProgress.pendingProps;
switch (workInProgress.tag) {
// ... 其他 tag 的处理 ...
// 当我们遇到 HostComponent（DOM 节点）时
case HostComponent: {
const type = workInProgress.type;
// 获取当前 DOM 节点
const currentProps = current !== null ? current.memoizedProps : null;
const nextProps = workInProgress.memoizedProps;
// 1. 处理 Ref
// Ref 的处理比较独立，我们稍后单独说
if (current !== null && nextProps.ref !== currentProps.ref) {
workInProgress.flags |= Ref;
}
// 2. 处理 DOM 节点的创建
// 这里调用了 updateHostComponent，它会处理 DOM 的挂载和更新
// 这里我们简化一下，只看核心逻辑
const nextInstance = updateHostComponent(
workInProgress,
type,
nextProps,
rootContainerInstance,
);
// 3. 核心逻辑：Placement 标志的设置
// 这就是我们要讲的“冒泡”逻辑之一
if (current === null) {
// 如果当前节点不存在（current 为 null），说明这是一个新节点
// 必须标记为 Placement！
// 这就好比你是第一次见到这个人，你得把他介绍给大家。
workInProgress.flags |= Placement;
}
// 4. 处理 Hydration（注水）
// 如果是服务端渲染的情况，这里还有一些复杂的逻辑，用来判断是插入还是更新
// ...略过 Hydration 代码 ...
return null;
}
// ... 其他 case ...
}
}代码解读与幽默时刻：
看第 36 行，if (current === null)。这是不是很简单？如果 current 是 null，说明这是个新来的，直接给个 Placement 标志。
但是，注意！ 这里仅仅是给当前节点（子节点）打了标签。真正的“冒泡”逻辑在哪里？
其实，completeWork 是一个递归过程。React 会先处理叶子节点，然后处理父节点。当 completeWork 递归回溯到父节点时，父节点会再次检查自己的子节点。如果子节点有 Placement 标志，父节点会把这个标志继承给自己。
这在源码中通常是通过 child.flags |= Placement 这样的逻辑实现的（具体位置在 beginWork 或者是 completeWork 的后续遍历逻辑中）。
逻辑流：
completeWork遇到一个新的<div>。- 发现
current是 null，给它打上Placement。 - 递归处理
<div>里的<button>。发现<button>也是新的，也打上Placement。 - 回到
<div>。completeWork处理完<button>后，发现<button有Placement标志。 <div>作为一个容器，必须保证里面的元素都在。于是，div也给自己打上Placement标志。
为什么要这样？
因为 DOM 的插入是有顺序的。如果不给父节点打标签，Commit 阶段可能只会先插入父节点，导致子节点插入失败，或者顺序错乱。父节点标记了 Placement，Commit 阶段就会确保在父节点插入后，再插入子节点。
第三部分：Update（更新）的博弈—— “虽然旧了，但我还能用”
如果说 Placement 是新人的入职，那 Update 就是老员工的绩效考核。
当 current 不为 null 时，说明这个节点在当前的 DOM 树里已经存在了。这时候，React 需要比较新旧属性，看看有没有变化。
// 伪代码示意
if (current !== null) {
const prevProps = current.memoizedProps;
const nextProps = workInProgress.memoizedProps;
// 比较属性
if (shallowEqual(prevProps, nextProps)) {
// 属性没变，不需要标记 Update
// 但是！如果子节点有 Update 标志，父节点得继承！
// 见下文
} else {
// 属性变了，必须标记 Update
workInProgress.flags |= Update;
}
}为什么父节点的 Update 标志这么重要？
这涉及到 React 的一个核心设计：按层级更新。
假设你有一个父组件 Parent 和子组件 Child。
Parent 传了一个 name="Alice" 给 Child。
Child 传了一个 style={{ color: 'red' }} 给 div。
现在，你只想改 Child 的颜色，不改 Parent 的名字。
React 在 Render 阶段会生成两个 Fiber 树。
在 completeWork 阶段：
Child发现style变了，给自己打上Update。Parent发现name没变，不给自己打Update。- 关键点来了：
completeWork在处理Parent时，发现它的孩子Child有Update标志。 - 于是，
Parent也给自己打上了Update标志。
为什么？因为如果 Parent 不更新，DOM 就会报错。比如 Parent 是一个 div，它包含了 Child。如果 Parent 不更新（即不重新渲染 Parent 的 DOM），那么 Child 的 DOM 就没法正确挂载在 Parent 下面，或者挂载在错误的位置。
代码中的体现（简化版）：
// 在 completeWork 的递归逻辑中（通常在 beginWork 的后续步骤或 completeWork 的遍历中）
// 我们需要确保父节点继承子节点的副作用
if (workInProgress.subtreeFlags !== NoFlags) {
// 如果子树有副作用，父节点也得有
workInProgress.flags |= (workInProgress.subtreeFlags & Update);
}这就像是老板（父节点）发现员工（子节点）在加班（Update），老板也得陪着加班，因为老板要负责给员工发工资（DOM 操作）。
第四部分：Deletion（删除）的忧伤—— “我是幽灵”
这是 React 源码中最让人心碎，但也最复杂的一个逻辑。
在 completeWork 中，我们主要处理的是“正在构建的新树”。但是，删除操作通常是“懒惰”的。
当你删除一个子节点时，React 不会立即在 completeWork 里把这个子节点标记为删除。相反，它会保留这个子节点在当前树中的引用，直到 Commit 阶段。
删除逻辑的“冒泡”是如何发生的？
想象一下，你删掉了 <div> 里的 <button>。
- Render 阶段结束，新树里没有
<button>了。 completeWork遍历完新树，发现<div>（父节点）还在。- 但是，在当前树中，
<div>下面已经没有<button>的 Fiber 了。 - React 会遍历当前树（旧树），找到那个被删掉的
<button>。 - 它会给那个
<button>打上Deletion标志。 - 然后，这个
Deletion标志会冒泡上去，直到打给<div>。
代码逻辑（简化）：
// 在 completeWork 的最后，或者单独的清理逻辑中
function commitDeletionEffects(root, nearestMountedAncestor, fiber) {
// 这是一个递归函数，用于标记删除
// 我们要找到所有被删除的节点，并向上冒泡
let nextFiber = fiber;
while (nextFiber !== null) {
const child = nextFiber.child;
const sibling = nextFiber.sibling;
// 1. 如果是 HostComponent（DOM 节点），标记删除
if (nextFiber.tag === HostComponent) {
nextFiber.flags |= Deletion;
}
// 2. 递归处理兄弟节点
if (child !== null) {
nextFiber = child;
} else if (sibling !== null) {
nextFiber = sibling;
} else {
// 3. 回溯到父节点，处理兄弟节点的兄弟
// 这就是冒泡的核心！
let parent = nextFiber.return;
while (parent !== null) {
// ...
if (sibling !== null) {
nextFiber = sibling;
break;
} else {
// 如果兄弟也没有了，继续找叔叔（父节点的兄弟）
nextFiber = parent;
parent = parent.return;
}
}
}
}
}深入理解：
在 completeWork 阶段，我们通常只关注“新树”的构建。但是，为了处理删除，React 实际上是在比较“新树”和“旧树”。
那个被删掉的 <button>，它已经不在 finishedWork（新树）的队列里了。它只存在于 current（旧树）中。
React 需要在 Commit 阶段处理这个“孤儿”。
Deletion 标志的冒泡非常关键。如果 <div> 没有被标记为删除，但它的子节点被标记为删除，那么 Commit 阶段可能会先删除子节点，导致 DOM 结构断裂（比如 div 下面空了，或者子节点被扔到了 body 下）。所以，父节点必须继承 Deletion 标志，以确保 DOM 操作的原子性。
第五部分：Ref（引用）的清理—— “别忘了和世界打个招呼”
Ref 是 React 中的一个小众但强大的特性。它允许你直接获取 DOM 节点的引用。
在 completeWork 中，我们处理 Ref 的逻辑比较简单，但也很重要。
case HostComponent: {
const type = workInProgress.type;
const currentProps = current !== null ? current.memoizedProps : null;
const nextProps = workInProgress.memoizedProps;
// 1. 检查 ref 是否变化
if (current !== null && nextProps.ref !== currentProps.ref) {
workInProgress.flags |= Ref;
}
// ... 创建 DOM ...
// 2. 如果是首次挂载，或者 ref 变了，我们需要在 commit 阶段处理
// 但在 completeWork 阶段，我们只需要标记一下
// ...
return null;
}Ref 的冒泡逻辑：
Ref 的冒泡逻辑比较特殊。它不依赖于父节点是否改变。
- 情况一：新节点。
如果是一个全新的组件，并且它有ref，那么completeWork会标记Ref。 - 情况二：节点存在，ref 变了。
completeWork会标记Ref。 - 情况三：节点被删除了。
如果一个节点被删除了，它的ref回调函数必须被调用（传入null）。
这意味着，即使父节点没有改变，如果子节点被删除了，父节点也需要继承Deletion标志（正如我们在第四部分讲的），并且 Commit 阶段会递归调用所有被删除节点的ref回调。
所以，Ref 的冒泡是依附于 Deletion 标志的。
第六部分：DidCapture（错误捕获）的惊悚—— “出事了！”
这是 React 16 引入的一个非常酷的特性，用于错误边界。
当一个子组件抛出错误时，React 会暂停渲染，把这个错误“捕获”起来，并把子组件标记为 DidCapture。
case HostComponent: {
// ... 其他逻辑 ...
// 如果子组件抛出错误
if (workInProgress.flags & DidCapture) {
workInProgress.flags &= ~DidCapture;
workInProgress.flags |= Update;
}
// ...
}为什么需要冒泡？
如果一个子组件抛出错误，这个错误会向上传播。父组件需要知道“哦，我的孩子出事了，我需要执行 componentDidCatch 生命周期或者错误边界逻辑”。
DidCapture 标志的冒泡意味着，如果一个子节点有这个标志，它的所有父节点都必须继承这个标志。这样，Commit 阶段才能确保父组件有机会执行错误处理逻辑。
代码逻辑（简化）：
// 在 completeWork 的遍历逻辑中
if (workInProgress.subtreeFlags & DidCapture) {
workInProgress.flags |= DidCapture;
}这就像是一个坏消息在家族群里传播。孙子摔倒了（DidCapture），爷爷（父节点）必须知道，以便赶紧去扶。
第七部分：Snapshot（快照）的注水之战—— “这是服务器渲染的尸体吗？”
这部分稍微高级一点，涉及到服务端渲染（SSR）。
当 React 在 completeWork 阶段遇到已经存在于 DOM 中的节点（Hydration 阶段），它需要进行比对。如果发现 DOM 节点的内容和 React 预期的不同，React 会把那个 DOM 节点“扔掉”，重新创建。
这个“扔掉”的过程，就涉及到了 Snapshot 标志。
case HostComponent: {
// Hydration 逻辑
if (current !== null) {
// 检查 DOM 是否匹配
if (!didHydrate) {
// 发现不匹配！
workInProgress.flags |= Snapshot; // 标记快照
// ... 丢弃 DOM ...
}
}
}Snapshot 的冒泡逻辑：
如果一个子节点因为不匹配而被标记为 Snapshot（需要被丢弃），那么它的父节点必须也标记为 Snapshot。为什么？因为父节点本身可能也需要被丢弃，或者需要重新渲染，以容纳这个新的子节点结构。
这就像是装修队发现墙纸颜色不对。他们不能只撕掉墙纸（子节点），还得把墙砸了（父节点），因为墙纸贴在墙上，墙不对，墙纸也没法贴。
第八部分：代码实战—— 一个完整的 completeWork 流程
让我们把前面所有的知识点串起来，看一个完整的例子。
假设我们有这样一个 JSX：
<div id="app">
<span className="old">Hello</span>
</div>现在我们把它改成：
<div id="app">
<span className="new">World</span>
</div>Render 阶段：
React 创建了新的 Fiber 树。
CompleteWork 阶段（递归）：
-
处理
div(父节点)：current存在（旧的div）。props.id相同，没有Placement。- 但是，它的子节点有变化。
- 冒泡逻辑：
div发现subtreeFlags有Update（因为子节点变了）。 - 结果：
div打上Update标志。
-
处理
span(子节点)：current存在（旧的span）。props.className变了（old->new）。- 结果：
span打上Update标志。
-
Commit 阶段：
- React 遍历 Fiber 树。
- 先处理
span。发现Update，修改 DOM 的 class。 - 再处理
div。发现Update，更新 DOM 的属性（如果有）。 - 因为
div有Update，且div包含span，所以 DOM 更新顺序正确。
第九部分：Ref 和 Deletion 的悲伤故事
再来看一个删除的例子。
Render 阶段：
我们删掉了 <span>。
CompleteWork 阶段：
-
处理
div(父节点)：current存在。- 新树里没有
span。 - 冒泡逻辑： React 需要找到那个被删掉的
span。 - React 遍历旧树，给
span打上Deletion标志。 - 然后，这个
Deletion标志冒泡给div。div也打上Deletion标志。
-
Commit 阶段：
- React 遍历 Fiber 树。
- 先处理
div。发现Deletion。 - React 进入
div的子节点列表。 - 发现
span有Deletion。 - 执行 Ref 回调：
span.current = null。 - 移除 DOM：
div.removeChild(spanDOM)。 - 继续处理
div的下一个兄弟节点（假设没有）。 - 执行 Ref 回调：
div.current = null。 - 移除 DOM：
root.removeChild(divDOM)。
总结：
Deletion 标志的冒泡保证了 DOM 操作的顺序：先删孙子，再删儿子，最后删老子。同时也保证了 ref 回调的顺序：先清理孙子，再清理儿子。
第十部分：总结—— completeWork 是个勤劳的搬运工
好了，同学们，今天的讲座接近尾声。
我们回顾一下 completeWork 在副作用标志冒泡中的核心职责：
- Placement（插入）： 当节点是全新的，它必须打上标签，并且父节点必须继承这个标签，以确保 DOM 插入顺序正确。
- Update（更新）： 当节点属性变化，它必须打上标签，父节点必须继承，以确保父组件的容器属性（如 key, ref）正确更新。
- Deletion（删除）： 这是最复杂的。React 会在旧树中找到被删的节点，给它打上
Deletion，然后一路向上冒泡给父节点，确保 DOM 移除顺序和 Ref 回调的正确执行。 - Ref（引用）： 虽然它通常依附于 Placement 或 Deletion，但它的冒泡确保了所有被创建或销毁的组件都能正确地与 React 世界断开或建立联系。
- DidCapture & Snapshot： 错误处理和 Hydration 特有的标志，它们必须冒泡，以确保错误边界和 SSR 的正确恢复。
最后，送给大家一句话：
React 的 completeWork 就像一个尽职尽责的管家。他在深夜里（Render 阶段结束），把你家里所有乱七八糟的家具（子节点）都检查了一遍。他给新搬进来的家具贴上“入住”标签（Placement），给旧家具贴上“翻新”标签（Update），把准备扔掉的家具贴上“打包”标签（Deletion），最后，他还给所有家具的钥匙（Ref）都整理了一遍。
等到第二天早上（Commit 阶段），工人来了，直接看管家贴的标签干活，效率极高，乱不了套。
希望大家通过今天的讲解，对 React 的源码有了更深的理解。代码虽然难懂，但逻辑是相通的。保持好奇心，保持对细节的追求，你就是那个“资深编程专家”！
下课！