各位 React 的探险家们，下午好！
欢迎来到 DOM 的后花园。今天我们要聊的不是那些花里胡哨的 Hooks，也不是那些让你抓耳挠腮的闭包陷阱，而是我们要去扒一扒 React 内裤——或者说，它的核心逻辑——在处理文本节点时的那些小心思。
我们都知道，React 的口号是“声明式”。你告诉它“我想显示这个字符串”，然后它就乖乖地去操作 DOM。但如果你真的去打开浏览器的开发者工具，或者在 React 18 的并发模式里仔细观察，你会发现一个诡异的现象：为什么我的代码里明明只有一个 <div> 包裹着一个字符串，DOM 里却可能存在一堆乱七八糟的文本节点？
比如，你写了 <div>Hello {name}</div>，结果 React 给你渲染出来的 DOM 可能长这样：
<div>
<!-- React 认为这是安全的 -->
<span></span>
<!-- 然后才是你的文本 -->
Hello
<!-- 甚至可能还有个孤儿 -->
<span></span>
World
</div>是不是感觉头皮发麻？这就像是你的房子明明只需要一个房间，装修队却给你砌了三堵墙，中间还留了两个空盒子。这不仅仅是“美观”问题，这关乎性能，关乎浏览器如何解析内容。
今天，我们就要把 React 的协调阶段（Reconciliation Phase）像剥洋葱一样剥开，看看它是如何通过一套精妙的逻辑判定，把那些散落在 DOM 树里的“文本碎片”给强行吞并，或者至少是整理得井井有条的。
一、 DOM 的“洁癖”与 React 的“混乱”
首先，我们要理解浏览器 DOM 的性格。DOM 是一个树形结构，但这个树不仅仅是节点。在 HTML 规范里，节点分为元素节点（<div>）、属性节点（class）和文本节点（Hello）。
文本节点是尴尬的。它们不像 <div> 那样是一个容器，它们只是内容。如果你在一个 <div> 里面放了两个文本节点：
<div>
Hello
World
</div>这在浏览器里是合法的，但非常低效。浏览器在渲染时，需要不断地切换上下文，去处理这两个孤立的文本节点。所以，浏览器（以及 React 作为一个优秀的框架）都有一个共识：同一个父元素下的连续文本，最好合并成一个。
这就是为什么 React 要在协调阶段进行“合并”。
二、 Fiber：不是树，是链表
在深入代码之前，我们必须先纠正一个观念。React Fiber 不仅仅是一个树，它本质上是一个链表。
每一个 Fiber 节点都有三个核心指针：
return：指向父节点（孩子找爸爸）。child：指向第一个子节点（爸爸找第一个孩子）。sibling：指向下一个兄弟节点（爸爸找二儿子）。
这个结构非常关键。当你看到 React 协调时，它实际上是在遍历这个链表。如果你在代码里写的是：
<div>
<span>Hello</span>
<span>World</span>
</div>在 Fiber 树里，div 节点的 child 指向 span，而 span 的 sibling 指向另一个 span。
但如果你的代码是：
<div>
Hello
World
</div>React 怎么处理？它不能把“Hello”和“World”都变成 div 的 child，因为它们不是元素，它们是文本。所以，React 可能会创建一个临时的“容器”节点，或者直接在逻辑层面把它们合并。
三、 核心战场：reconcileSingleChild
React 渲染的核心入口通常在 ReactFiberReconciler.js 里的某个地方。当 React 决定要渲染一个节点时，它会调用 reconcileChildren。对于大多数单子节点的情况，它会调用 reconcileSingleChild。
这个函数是今天讲座的重头戏。它的任务很简单：接收父 Fiber 节点，接收新的子元素（可能是字符串、数字，也可能是 JSX 对象），然后返回处理后的 Fiber 节点。
让我们来看看这个函数的简化版逻辑（源码逻辑极其复杂，这里我们只看核心的“合并”逻辑）：
function reconcileSingleChild(
returnFiber: Fiber,
currentFirstChild: Fiber | null,
newChild: any,
) {
// 1. 判定新子节点是不是文本节点
const isStringOrNumber = typeof newChild === 'string' || typeof newChild === 'number';
// 2. 如果是文本节点，进入“合并”逻辑
if (isStringOrNumber) {
// 这里的逻辑非常微妙，我们稍后细说
return placeSingleChild(returnFiber, currentFirstChild, newChild);
}
// ... 其他逻辑，比如处理数组、Fragment 等
}
function placeSingleChild(returnFiber, currentFirstChild, newChild) {
// 关键函数：placeSingleChild
// 它决定了这个文本节点是作为独立的子节点挂载，还是被“吞”进父节点里
}看到没？placeSingleChild 就是那个拿着手术刀的医生。它决定了文本节点的命运。
四、 逻辑判定：什么时候“合并”，什么时候“分裂”？
这是最令人困惑的地方。为什么有时候 React 会给你渲染一堆 <span> 包裹的文本，有时候又直接把文本挂在父节点上？
这取决于 React 对“子节点列表”的判断。
场景 A：React 认为你是“多子节点”
假设你写了：
<div>
<span>Hello</span>
<span>World</span>
</div>React 在协调阶段看到，你的父节点 div 期望有一个列表：[<span>, <span>]。
此时，React 不会把 Hello 和 World 合并成一个文本节点。因为 React 视觉上认为 div 里面有两个子元素（两个 <span>）。React 会忠实地保留这两个 <span> 节点。
场景 B：React 认为你是“单子节点”
现在，你把代码改了：
<div>
{name === 'Tom' ? <span>Hello</span> : 'Hello'}
</div>或者更简单的：
<div>
Hello
</div>在 React 的眼里，div 的子节点列表现在只有一个元素。这个元素是一个字符串 "Hello"。
这时候，placeSingleChild 就开始工作了。它需要判断：我是把这个字符串变成一个独立的 Fiber 节点挂载在 div 下，还是把它“偷”过来，直接变成 div 的文本？
五、 吞并逻辑的魔法：lastEffect 链
这里就要祭出 React 的核心黑科技了——副作用链。
在 React 18 之前，或者更准确地说，在协调阶段处理副作用时，每个 Fiber 节点都有一个 firstEffect 和 lastEffect。这两个属性连接着一系列需要被处理的 DOM 操作。
当 React 决定合并文本节点时，它会检查父节点是否已经有“副作用”了。
想象一下这个场景：
// 父节点 div 已经有一些渲染任务了
divFiber.lastEffect = someEffectNode;如果 divFiber.lastEffect 不为 null，这意味着 div 里已经有一些东西需要渲染了（比如里面有一个 <span>）。
这时候，React 不会把文本节点变成 div 的 child，因为 div 已经有 child 了（那个 <span>）。
React 会做一件非常聪明的操作：把文本节点的副作用挂载到父节点的 lastEffect 上。
代码逻辑大概是这样的（极度简化）：
if (typeof newChild === 'string' || typeof newChild === 'number') {
// 如果父节点已经渲染过其他东西了（lastEffect 存在）
if (returnFiber.lastEffect !== null) {
// 1. 把当前的文本节点挂载到父节点的副作用链表末尾
const effect = createEffect(newChild); // 创建一个文本变更的副作用
returnFiber.lastEffect.nextEffect = effect;
returnFiber.lastEffect = effect;
// 2. 关键点：返回 null！
// 这意味着 React 认为没有创建新的 Fiber 节点，而是直接利用了父节点的容器。
// 浏览器在渲染时，会读取父节点 `div` 的子节点列表。
// 因为父节点没有新的 child，所以浏览器就只渲染 `div` 原有的子元素。
// 但是！副作用链告诉浏览器：“嘿，在渲染完 div 的子元素后，请把这段文本也渲染出来！”
return null;
}
// 3. 如果父节点没有渲染过东西，那就比较简单了
// 直接把文本节点变成 div 的子节点
return createFiber(newChild, returnFiber);
}这就是“合并”的本质！
它并没有在 DOM 结构上真的把文本节点“合并”成一个字符串（因为 DOM 必须是节点），它在逻辑上欺骗了 React：“这个文本节点其实不属于子节点列表，它属于父节点的内容流。”
六、 代码示例：模拟 React 的内心戏
为了让你彻底明白，我们来手写一个极简版的 React 协调器。不要害怕，我们只关注文本节点。
class Fiber {
constructor(type, props, returnFiber) {
this.type = type; // 'div', 'span', 或者 'TEXT'
this.props = props;
this.return = returnFiber; // 父节点
this.child = null; // 第一个子节点
this.sibling = null; // 下一个兄弟节点
this.effectTag = null; // 效果标记
}
}
// 模拟协调器
function reconcileChildren(returnFiber, newChildren) {
let currentFirstChild = returnFiber.child;
// 假设我们只有一个子节点，且是文本
const newChild = newChildren[0];
// 逻辑判定
if (typeof newChild === 'string') {
// 情况 1: 父节点已经有子节点了（比如父节点里有个 <span>）
if (currentFirstChild !== null) {
console.log("情况1：父节点已有子节点，文本被挂载到副作用链");
// 实际上 React 会把文本节点的 effect 挂到 currentFirstChild.lastEffect
// 这里我们简化为直接操作 DOM
appendTextToDOM(returnFiber.domNode, newChild);
return null; // 不创建新的 Fiber
}
// 情况 2: 父节点是空的（或者 React 认为它是单子节点）
console.log("情况2：父节点无子节点，文本直接作为子节点");
const child = new Fiber('TEXT', null, returnFiber);
child.domNode = document.createTextNode(newChild);
returnFiber.child = child;
return child;
}
}
// 假设的渲染函数
function appendTextToDOM(parentNode, text) {
// 模拟 React 的副作用执行
// React 会找到父节点的 lastEffect，然后执行 appendChild
console.log(`正在向 DOM 添加文本: ${text}`);
parentNode.appendChild(document.createTextNode(text));
}当你运行这个模拟代码时，你会发现：
- 如果你一开始在
<div>里放了一个<span>，然后修改文本，appendTextToDOM会被调用，但 DOM 结构里多了一个文本节点。 - 如果你一开始
<div>是空的，React 会创建一个Fiber节点作为child。
七、 为什么 React 要这么麻烦？
你可能会问：“这有什么意义？反正最后都要渲染出来。”
意义在于性能和 DOM 操作的原子性。
假设你有 100 个文本节点在同一个父节点下。如果 React 不合并，它可能会创建 100 个 Fiber 对象，并在协调阶段遍历 100 次逻辑。虽然现代 JS 引擎很快，但这是不必要的开销。
更重要的是浏览器渲染性能。
浏览器在绘制（Paint）阶段，会遍历 DOM 树。如果 DOM 树里充满了孤立的文本节点，浏览器的重排（Reflow）和重绘（Repaint）成本会成倍增加。React 通过这种“吞并”逻辑，确保了同一个父容器下的文本操作是尽可能连续的。
八、 深入：ChildReconciler 的复杂逻辑
在 React 源码中，逻辑比我们讲的还要复杂。placeSingleChild 函数不仅仅处理文本，它还处理其他类型的单子节点。
React 内部有一个 childIsString 的变量。这个变量会在遍历子节点列表时被设置。
// ReactFiberReconciler.js (简化逻辑)
function reconcileChildrenImpl(
returnFiber,
currentFirstChild,
newChildren,
lanes,
) {
let resultingFirstChild = null;
let previousNewFiber = null;
let oldFiber = currentFirstChild;
// 遍历新的子节点列表
for (; oldFiber !== null || newChildren !== null; ) {
// ... 这里处理 diff 算法，更新或删除节点 ...
// 关键点：子节点列表逻辑
// 如果新子节点是字符串/数字，React 会设置一个标志
if (typeof newChild === 'string' || typeof newChild === 'number') {
// ...
}
}
}React 的协调器非常聪明，它会在遍历列表时，动态判断当前处理的是否是“孤立的文本”。
如果列表是 ['A', 'B']，React 会处理 A，然后处理 B。
如果列表变成了 ['A']（只有一个文本），React 会触发 placeSingleChild。
九、 调试：如何看到这个魔法？
如果你想亲眼看到 React 的“吞并”行为，可以使用 React 18 的 createRoot 和 flushSync 配合 ReactDebugHooks。
但最直观的方法是观察 React 的调试面板。
在 React 18 中，当你使用 createRoot 时，React 会自动启用调试模式。如果你在 React.render 或 createRoot 里加上 ReactDebugHooks 的代理，你会发现控制台里会打印出很多关于 Fiber 节点创建的信息。
特别是，你会看到这样的模式：
- 当你删除一个元素时，React 并没有真的删除 DOM 节点，而是把
effectTag设置为Deletion，然后把这个节点的effect挂载到父节点的lastEffect链上。 - 当你修改文本时，React 也是这样做的。
十、 边缘情况：Fragment 的干扰
有时候，React 的合并逻辑会被 Fragment 打断。
<div>
<React.Fragment>Hello</React.Fragment>
<span>World</span>
</div>React 把 Fragment 视为特殊的节点。在协调阶段，Fragment 本身不渲染任何东西，但它会展开它的子节点。
如果 Fragment 里面只有一个文本节点，React 会试图把这个文本节点“提升”到 div 下面，因为它认为 div 的直接子节点列表应该是 [<span>, Text]。这种“提升”行为也是为了减少 Fragment 这个空壳节点对 DOM 结构的污染。
十一、 总结：从“节点”到“流”
通过这次深入剖析，我们看到了 React 协调阶段的一个核心艺术：抽象。
React 并不直接把虚拟 DOM 映射为 DOM 节点，它是在映射为“副作用流”。
当你写 Hello 时，你以为是“一个字符串”。
React 看到的是“一个需要被渲染的副作用”。
当这个副作用被判定为“父节点的附属物”时，React 就会把它挂载到父节点的副作用链表末尾，而不是创建一个新的子节点对象。
这就解释了为什么有时候你会看到 <span></span>Hello 这种奇怪的 DOM 结构（因为 React 试图把文本节点和前面的元素节点区分开，或者因为某些特定的逻辑判定）。
但也解释了为什么大多数时候，DOM 结构看起来是整洁的，文本节点被巧妙地融合了。
这就像是一个完美的管家，他不会在你家里到处乱扔纸团（文本节点），他会把它们捡起来，整整齐齐地放在垃圾桶（父节点）里，然后告诉你：“主人，垃圾桶满了，该清理了。”
这就是 React 文本节点合并机制的精髓。它不是魔法，它是基于链表操作和副作用管理的精密工程。下次当你看到控制台里那些 #text 节点时，你可以会心一笑：那是 React 正在努力地维持着 DOM 树的优雅与秩序。
好了，今天的讲座就到这里。现在，去你的代码里找找那些被“吞并”的文本节点吧！