大家好！欢迎来到今天的“React 内部解剖课”。我是你们的讲师，一个在 React 代码里摸爬滚打多年的资深“外科医生”。
今天我们不聊 useEffect 的坑，也不聊 useState 的闭包陷阱，我们要聊的是 React 的灵魂——跨平台抽象。
想象一下，React 是一个天才的指挥官，他脑子里有一个完美的世界。但是，这个世界里没有 DOM 节点，没有 document.getElementById，没有 window，甚至没有屏幕。React 只有一堆逻辑：这个节点该存在吗？那个属性该不该变？这个子节点该不该删？
那么，谁来把这些“逻辑”变成屏幕上闪烁的像素呢？谁来把这些“逻辑”变成 iOS 屏幕上的 UIView，或者变成安卓的 ViewGroup？
这就引出了我们今天的核心话题：HostConfig 接口协议。
你可以把 HostConfig 理解为 React 指挥官和底层宿主（Host）之间的翻译官，或者更直白点说，是“脏活累活执行者”。
而 react-dom，只是这个翻译官的一个实现版本。它的兄弟 react-native，是另一个版本。它们虽然长得不一样，但都在做着同样的事情：遵守协议，干活。
好，让我们把手术刀拿出来，切开 react-dom 和 react-reconciler，看看它们到底是怎么勾搭在一起的。
第一部分：契约精神——HostConfig 是什么？
在深入代码之前，我们得先看看这个“契约长什么样”。
如果你去翻阅 React 的源码（尤其是 packages/react-reconciler/src/ReactFiberHostConfig.dom.js 或者 ReactFiberHostConfig.dom.prod.js），你会发现并没有一个叫 HostConfig 的类。它是一个 TypeScript 接口定义（或者 JSDoc 类型），定义在 packages/react-reconciler/src/ReactFiberHostConfig.js 里。
这就是 React 跨平台的核心哲学：核心逻辑与宿主实现解耦。
对于 React Reconciler 来说，它根本不在乎你在浏览器里渲染，还是在 PDF 里渲染，或者是在 VR 眼镜里渲染。它只知道一件事：“嘿，兄弟，我有个 DOM 节点要建，你给我个实例；我有个属性要改，你帮我改；我要把子节点插进去了，你帮我插。”
于是，react-dom 就在某个地方定义了这个接口的具体实现。
为了方便理解，我们假设这个接口长这样（简化版）：
// React Reconciler 期望的接口定义
type HostConfig = {
// 1. 创建节点
createInstance: (
type: string,
props: Props,
rootContainerInstance: Instance,
hostContext: HostContext
) => Instance;
// 2. 插入子节点
appendInitialChild: (
parentInstance: Instance,
child: Instance
) => void;
// 3. 更新属性
updatePayload: (
instance: Instance,
oldProps: Props,
newProps: Props
) => Payload;
// 4. 提交根节点（真正的“落笔”时刻）
commitRoot: (completedRoot: FiberRoot) => void;
// ... 还有几十个方法
};注意，这里没有 document.createElement，没有 element.style.color。一切都是抽象的 Instance 和 Payload。
第二部分：播种时刻——createInstance
当 React 的协调器（Scheduler + Reconciler）跑完 Diff 算法，发现：“哎哟，这里缺一个 <div>，或者这里要把一个 <span> 变成 <p>。”
协调器就会调用 HostConfig 的 createInstance。
在 react-dom 的世界里，这个函数非常简单粗暴：
// react-dom/src/client/ReactDOMHostConfig.js (简化)
function createInstance(type, props, rootContainerInstance, hostContext) {
// 1. 构造 DOM 元素
let domElement = document.createElement(type);
// 2. 处理所有属性
// 这里有个细节：React 会在创建时先处理所有属性，而不是逐个更新
// 这样能减少主线程的抖动
for (let propKey in props) {
if (props.hasOwnProperty(propKey)) {
setProperty(domElement, propKey, props[propKey], false);
}
}
return domElement;
}你看，协调器只传了 type 和 props。至于怎么创建，react-dom 拿着 type 去找浏览器 API。
如果是 react-native，这段代码就会变成：
function createInstance(type, props, rootContainerInstance, hostContext) {
// React Native 不用 document.createElement，而是用 RCTUIManager
// 它会生成一个 RCTView 或者 RCTText
return UIManager.createView(
UIManager.ViewManagerConfig.getConstants().UIManager,
type,
rootContainerInstance,
props
);
}这就是抽象的威力。Reconciler 根本不认识 document，它只认识 createInstance。react-dom 负责把 React 的逻辑翻译成浏览器的指令。
第三部分：插入逻辑——appendChild 与 insertBefore
节点建好了，接下来要插到哪去？
React 的 Fiber 树结构是单向的。在协调器眼里，父节点就是父节点，子节点就是子节点。
协调器会调用 appendChild 或 insertBefore。
1. appendChild (插入子节点)
如果协调器发现：“这个父节点现在少个孩子，把 A 插进来！”
react-dom 的实现：
function appendChild(parentInstance, child) {
// 简单粗暴，直接 appendChild
parentInstance.appendChild(child);
}2. insertBefore (指定位置插入)
如果协调器发现：“这个父节点现在有两个孩子，A 和 B。A 在前，B 在后。但现在我们要把 B 插到 A 前面，把 A 推到后面。”
react-dom 的实现：
function insertBefore(parentInstance, child, beforeChild) {
if (beforeChild) {
parentInstance.insertBefore(child, beforeChild);
} else {
// 如果 beforeChild 是 null，那就相当于 appendChild
parentInstance.appendChild(child);
}
}3. appendChildToContainer (插入到根节点)
这涉及到“容器”的概念。在 React 18 之前，ReactDOM.render 接收的是 container（比如 div#root）。在协调器看来，这个 container 也是一个节点。
所以，协调器会调用 appendChildToContainer。
react-dom 的实现：
function appendChildToContainer(container, child) {
const rootInstance = container; // 假设 container 本身就是 rootInstance
rootInstance.appendChild(child);
}而在 react-native 中，情况稍微复杂一点，因为它涉及到“层级”的概念（比如 ViewGroup 的嵌套）。但逻辑是一样的：找到父容器，把子视图加进去。
第四部分：重头戏——updatePayload
这是整个 HostConfig 协议里最精彩、最复杂，也是性能优化的关键所在。
当协调器发现：“哎，这个节点的属性变了！className 从 foo 变成了 bar，style.width 从 100px 变成了 200px。”
协调器不会傻乎乎地调用 element.style.color = 'red'，然后循环 100 次。
协调器会调用 updatePayload。
协调器视角：
// 协调器计算完差异后，会调用 HostConfig.updatePayload
const payload = [
'className', 'bar', // [name, value, name, value...]
'style.width', '200px',
'id', 'updated-id'
];
hostConfig.updatePayload(domElement, oldProps, newProps, payload);react-dom 视角：
updatePayload 返回的不仅仅是一个函数，而是一个描述变更的数组（或者说是“指令单”）。
function updatePayload(instance, oldProps, newProps, payload) {
if (!payload || payload.length === 0) return;
// React 18 的优化：它不会遍历 payload 去调用 setAttribute
// 而是直接操作 DOM 的属性
const domNode = instance;
// 这是一个非常底层的优化，直接操作 DOM 的 attributes 映射表
// 减少了函数调用的开销
const attributes = domNode.attributes;
const values = domNode._valueState; // React 内部维护的一个状态映射
// 遍历 payload，更新 DOM
for (let i = 0; i < payload.length; i += 2) {
const propKey = payload[i];
const propValue = payload[i + 1];
if (propKey === 'style') {
// 处理 style 对象
domNode.style.cssText = propValue;
} else {
// 处理普通属性
domNode.setAttribute(propKey, propValue);
}
}
}为什么这么设计？
因为协调器（Reconciler）和宿主（DOM）是分离的。协调器不知道 DOM 有 setAttribute，它只知道有个东西叫 updatePayload。React 团队通过这个协议，实现了极致的灵活性。
如果你想做一个渲染器，你不需要懂 Diff 算法，你只需要写好 updatePayload，告诉协调器：“嘿，给我一个 Payload，我负责把它变成 DOM 的变更。”
第五部分：卸载逻辑——removeChild
当协调器发现：“哦，这个节点不要了，删掉！”
它就会调用 removeChild。
react-dom：
function removeChild(parentInstance, child) {
parentInstance.removeChild(child);
}这看起来很简单，但背后有个逻辑陷阱。
在 DOM 中，removeChild 是从父节点移除子节点。但有时候，我们可能需要移除整个子树。
协调器会递归调用 removeChild 来处理子节点。它会先删掉最小的孩子，再删掉它的兄弟，最后删掉父节点。
但在 React Native 中，移除视图的逻辑和 DOM 有点不同。React Native 使用的是 unmountViewAtContainerIndex 之类的 API，或者通过层级管理器来移除视图。但接口协议依然是 removeChild，只是实现方式不同。
第六部分：Commit 阶段——commitRoot 与 commitBeforeMutationEffects
前面提到的 createInstance、appendChild、updatePayload，其实都是在协调器（Reconciler）阶段产生的指令。
真正的“执行”，发生在 Commit 阶段。
当协调器把整棵树都算完了，告诉调度器：“兄弟，活干完了，你可以去睡觉了，剩下的脏活累活（DOM 操作）交给 Commit 线程吧。”
Commit 线程会调用 HostConfig.commitRoot。
function commitRoot(root) {
// 1. commitBeforeMutationEffects
// 这里面处理 useLayoutEffect 的同步回调，以及 effectTag 为 Placement 的节点
commitBeforeMutationEffects(root.current);
// 2. commitMutationEffects
// 这里面处理 DOM 的真实变更：插入、更新、删除
commitMutationEffects(root.current, hostContext);
// 3. commitLayoutEffects
// 这里面处理 useLayoutEffect 的清理函数，以及 effectTag 为 Update 的节点
commitLayoutEffects(root.current, hostContext);
// 4. flushPassiveEffects
// 异步处理 useEffect
flushPassiveEffects();
// 5. 完成
root.finishedWork = null;
}commitBeforeMutationEffects（布局效应前置）
在这个阶段，React 会处理 useLayoutEffect。为什么叫“Before Mutation”？因为 useLayoutEffect 的回调是同步执行的，而且要在浏览器把画面画出来之前（也就是在 DOM 真正变之前）就执行。
如果协调器标记了一个节点需要“布局更新”，Commit 线程会调用 commitBeforeMutationEffectsOnFiber。
function commitBeforeMutationEffectsOnFiber(fiber) {
switch (fiber.effectTag) {
case Placement:
// 这里的 Placement 已经处理完了，但在 commitBeforeMutationEffects 里
// 我们还需要做一些特殊的布局计算
break;
case Update:
// 调用 HostConfig 的 updatePayload
const instance = fiber.stateNode;
const updatePayload = fiber.updateQueue;
// 注意：这里调用的是 updatePayload，但它和协调器调用的不一样
// 这里的 updatePayload 是 React 18 的新机制，用于优化
commitUpdate(instance, updatePayload);
break;
}
}commitMutationEffects（变异效应）
这是真正的 DOM 操作发生的地方。
React 会遍历 Fiber 树，根据 effectTag 来决定做什么：
- Placement (插入): 调用
appendChild或insertBefore。 - Update (更新): 调用
updatePayload。 - Deletion (删除): 调用
removeChild。
React 会使用一个“工作栈”来遍历树，保证父节点在子节点之前被操作（或者根据特定的规则，比如先删子节点再删父节点，这涉及到副作用链的处理）。
commitLayoutEffects（布局效应）
DOM 变完了，现在可以安全地执行 useLayoutEffect 了。
react-dom 会调用 commitLayoutEffectOnFiber：
function commitLayoutEffectOnFiber(fiber) {
if (fiber.tag === FunctionComponent || fiber.tag === ClassComponent) {
const instance = fiber.stateNode;
// 执行 useEffect 的 layout 阶段回调
if (typeof instance.componentDidMount === 'function') {
instance.componentDidMount();
}
}
// 收集子节点的 layout effects
commitLayoutEffects_begin(fiber);
commitLayoutEffects_complete(fiber);
}第七部分：水合——hydrateInstance
这又是一个 React 18 的重头戏。
以前，React 渲染是“从零开始”。浏览器里有 HTML，React 拿到 HTML，然后把它变成自己的 Fiber 树。
现在，React 支持“水合”。
场景是这样的：服务器端渲染了 HTML，直接扔给浏览器。浏览器里已经有了 HTML。
React 怎么知道浏览器里的这个 <div> 是不是和 React 期望的 <div> 一样？
它需要“验证”。
协调器在遍历 DOM 树时，会调用 HostConfig.hydrateInstance。
// react-dom 的 hydrateInstance 实现
function hydrateInstance(
instance,
type,
props,
rootContainerInstance,
hostContext
) {
// 1. 验证节点类型
if (instance.nodeType !== ELEMENT_NODE || instance.nodeName.toLowerCase() !== type) {
throw new Error(...); // 类型不匹配！
}
// 2. 验证属性（关键！）
// React 会检查 id、className、data-* 属性等
// 如果不匹配，React 会报错，然后回退到客户端渲染
for (let propKey in props) {
const propValue = props[propKey];
// 检查 DOM 属性是否和 props 一致
// 比如 <div id="foo" />，浏览器里必须有 <div id="foo" />
if (shouldAutoFocusInput(propKey, propValue)) {
// 处理自动聚焦
} else {
// 检查属性是否存在且匹配
if (propValue !== getFiberCurrentPropsFromNode(instance)[propKey]) {
// 如果不一致，说明服务器端渲染错了，或者浏览器被篡改了
throw new Error('Hydration failed because the initial UI does not match what was rendered on the server.');
}
}
}
// 3. 如果一切正常，返回这个 DOM 节点，React 就开始复用它了
return instance;
}如果验证失败，React 会抛出错误，然后停止水合，重新走一遍 createInstance 的流程（变成客户端渲染）。
第八部分：自定义渲染器——Next.js 与 React Native
说了这么多 react-dom，我们来看看它是如何被“替换”的。
1. React Native
这是最经典的例子。React Native 根本没有 document 对象。
在 react-native 的 ReactNativeHostConfig.js 中，所有的 createInstance 都变成了调用 NativeModules.UIManager。
所有的 appendChild 都变成了调用 NativeModules.UIManager.setLayoutDirection 或 addView。
所有的 updatePayload 都变成了调用 NativeModules.UIManager.updateView。
React Native 甚至不需要浏览器，它直接通过 JavaScript Core (JSC) 或者 Hermes 引擎，把指令发给原生的 UI 线程。React Reconciler 根本不知道有浏览器，它只通过 HostConfig 和原生层对话。
2. Next.js (SSR/SSG)
Next.js 的 react-dom/server 其实也是利用了 HostConfig 的变体。
在服务器端渲染时，HostConfig 不指向浏览器，而指向一个内存中的“虚拟 DOM”或者直接指向一个字符串生成器。
createInstance 可能返回一个字符串片段 <div>。
appendChild 可能是字符串拼接 buffer += child。
updatePayload 可能是字符串替换。
这样，React 就能在服务器上生成 HTML 字符串，然后通过 hydrate 拿回浏览器。
第九部分：总结——为什么我们需要这个协议？
好了，咱们来总结一下，为什么 React 要搞这么复杂？
- 性能：
updatePayload的设计，避免了协调器在 Diff 算法阶段频繁调用宿主 API。协调器只算数，宿主只干活。算数很快，干活（DOM 操作）很慢。 - 解耦： React 团队可以随意修改协调器的算法（比如从 Stack Reconciler 变成 Fiber Reconciler），而不用改
react-dom的代码。只要react-dom继续实现HostConfig接口就行。 - 跨平台： 你想写一个 React 渲染器，不需要懂 React 的 Diff 算法，只需要写好
HostConfig。这就是为什么会有react-three-fiber（渲染到 WebGL），react-pdf（渲染到 PDF）。
一句话概括：
react-reconciler 是大脑，负责思考（计算差异）；HostConfig 是神经，负责传递指令；而 react-dom（以及各种自定义渲染器）是手脚，负责把指令变成现实。
如果你能看懂 HostConfig 的每一个方法，你就真正掌握了 React 的骨架。下次当你写 ReactDOM.render 时，你应该能看到那隐形的接口协议在空气中闪烁着金色的光芒。
好了，今天的解剖课就到这里。下课！记得去把你的 useLayoutEffect 改成 useEffect，除非你真的知道为什么需要同步执行。
（完）