各位前端界的“CPU 挖矿工”们，大家晚上好！
我是你们的老朋友，一个在 React 源码里摸爬滚打、头发日渐稀疏但技术日益精湛的资深工程师。今天，我们不聊业务需求，不聊 UI 设计，我们来聊点硬核的、有点“湿漉漉”的东西——Hydration（注水）。
大家都知道 React 18 带来了并发模式。这玩意儿听起来很玄乎，像是什么量子物理或者咖啡因过量的产物。但如果你真的去啃源码，你会发现，并发模式的核心其实就是两个字：优先级。
而“注水”，就是并发模式在这个特定场景下的集大成者。它解决了什么问题？它解决了“服务端渲染（SSR）的 HTML 虽然很快到了，但还没被 JavaScript 逻辑锁住，导致用户点击时还得傻傻等待 JS 注水完成”的尴尬局面。
今天，我们就把 React 的源码像剥洋葱一样剥开，看看它是如何利用 Lane（车道） 优先级系统，实现渐进式注水的。准备好了吗？让我们把发际线向后梳一梳，开始这场源码探险！
第一章：注水是什么？别喝错了！
在讲并发模式之前，我们必须得搞清楚什么是“注水”。很多人以为注水就是把服务器传来的 HTML 拼接到页面上，那叫“拼接”，不叫注水。
真正的注水，是一场“身份认证”。
想象一下，你（浏览器）面前有一堆 HTML 代码，这是服务端渲染出来的。这些 HTML 是“裸奔”的，它不知道自己是谁，也不知道点击它会有什么反应。它就像一个没穿衣服的游客。
然后，你的客户端 JavaScript（React）来了。React 会拿着这些 HTML，去对照它在内存里构建的虚拟 DOM 树。如果匹配上了，恭喜你，你穿上了衣服（挂载上了事件监听器，拥有了状态）；如果匹配不上，对不起，你把衣服扒了，重新渲染（卸载重挂）。
HydrationState 就是这段“身份认证”的记录本。
在 React 18 之前，这个认证过程是同步的、阻塞的。如果你有 1000 个节点需要认证，那用户点击按钮的时候，React 还在认证第 500 个节点，导致点击无响应。用户体验极差，就像你在点奶茶，收银员还在慢吞吞地核对会员卡积分。
并发模式的出现，就是为了解决这个问题。它引入了 Lane（车道） 优先级，把“注水”这个任务变成了一个可以被中断、可以被降级、可以被插队的任务。
第二章：Lane 车道系统——高速公路的限行规则
要理解渐进式注水，必须先理解 Lane。Lane 是 React 18 引入的一个位掩码系统，用来表示任务的优先级。
你可以把 Lane 想象成一条高速公路。我们有很多车道，每个车道代表一种优先级。
- Input Lane（输入车道）： 最高优先级。用户正在打字、点击按钮。这车道必须畅通无阻。
- Action Lane（动作车道）： 用户点击了提交按钮。
- Continuous Lane（连续车道）： 动画帧更新。
- Hydration Lane（注水车道）： 重点来了！ 这就是我们今天的主角。它的优先级相对较低，因为它不能阻塞用户的输入。
React 内部定义了一个 Lanes 对象，它是一个 31 位的整数。
// 源码简化版：Lane 定义
const NoLanes = 0b00000000000000000000000000000000;
const InputLane = 0b00000000000000000000000000000001; // 1号车道
const HydrationLane = 0b00000000000000000000000000000010; // 2号车道
const IdleLane = 0b00000000000000000000000000000100; // 3号车道
const ... // 还有很多车道核心逻辑：
当一个任务（比如用户的点击）进来时，React 会把这个任务分配到高优先级车道（比如 InputLane）。此时，如果后台有一个低优先级的“注水任务”正在 HydrationLane 上跑，React 会怎么做？
它会暂停注水任务！因为它知道，用户正在跟你交互，你不能让用户等。
这就是并发模式的第一条铁律：高优先级任务永远优先于低优先级任务。
第三章：hydrateRoot —— 搭建注水的大本营
当我们使用 hydrateRoot 时，React 做了什么？它不仅仅是在 DOM 上挂载一个根节点，它还初始化了一个注水状态机。
我们来看源码中 hydrateRootImpl 的核心逻辑（简化版）：
function hydrateRootImpl(
container,
children,
options,
rootContainerElement,
hostContext,
hydrationCallbacks,
isConcurrent,
morphExistingNode
) {
// 1. 创建 Fiber 树（虚拟 DOM 树）
const root = createFiberRoot(container, isConcurrent);
// 2. 关键一步：创建 HydrationState
// 这是一个数组，用来记录哪些节点已经注水了，哪些节点还没注水
// 比如：[null, 'div', null, 'span']
const hydrationCandidates = [];
const hydrationScripts = [];
const hydrationState = {
isPending: false,
pendingRoot: null,
// ... 更多状态
};
// 3. 将这个状态挂载到 root 上
root.hydrationState = hydrationState;
// 4. 创建根 Fiber
const rootFiber = createRootFiberFromChildren(
children,
hydrationState,
hydrationCallbacks
);
rootFiber.stateNode = root; // 关联 Fiber 和 Root
// 5. 更新容器
updateContainer(rootFiber, root, null, null);
return root;
}看懂了吗？HydrationState 就像是 React 的一个“备忘录”。它告诉 React：“嘿，我面前有一堆 HTML，这些节点里，有些是已知的，有些是未知的。我们在注水过程中，要时刻参考这个备忘录。”
第四章：scheduleHydrationWork —— 谁来决定注水的节奏？
这是源码中最迷人也最复杂的一个函数。它的作用是：决定是否要开始注水，以及注水的优先级是多少。
当 React 开始渲染（renderRootSync 或 renderRootConcurrent）时，它会调用 scheduleHydrationWork。
// 源码简化版：scheduleHydrationWork
function scheduleHydrationWork(root, lanes) {
// 1. 检查是否已经有正在进行的注水任务
if (root.hydrationState.isPending) {
// 如果正在注水，那就把新的优先级（lanes）合并进去
// 使用位运算 OR 操作
root.hydrationState.pendingLanes |= lanes;
return;
}
// 2. 如果没有正在进行的注水任务，那我们就开始吧！
root.hydrationState.isPending = true;
root.hydrationState.pendingRoot = root;
// 3. 核心逻辑：调度注水
// 我们要调度的优先级，取决于当前传入的 lanes 和 HydrationLane 的关系
const hydrationLane = pickHydrationLane(lanes);
// 4. 把 HydrationLane 加入到待处理的 Lane 列表中
// 这意味着：React 开始把“注水”作为一个高优先级的任务加入调度队列
root.pendingLanes |= hydrationLane;
// 5. 执行调度
// 注意：这里传入的是 hydrationLane，而不是所有的 lanes
// 这是为了保证注水任务本身不会阻塞其他更紧急的任务
requestHydrationCallback(root, hydrationLane);
}这里的 pickHydrationLane 是个天才设计。
如果用户刚刚点击了按钮（InputLane），React 会优先处理点击。此时，lanes 是 InputLane。pickHydrationLane 会返回 HydrationLane 吗？不会！它会返回一个更低的优先级，或者直接返回 NoLane。
这就好比：虽然老板（用户点击）喊你去开会，但前台（Hydration）正在打电话订午餐。老板来了，前台会挂断电话，去开会。等开完会，前台再决定要不要继续订午餐，或者干脆去吃外卖了。
这就是渐进式注水的精髓：注水任务不是一上来就全速跑的，它必须“看人下菜碟”。
第五章：performHydrationWork —— 渐进式注水的执行
现在，scheduleHydrationWork 把注水任务扔进了调度器。接下来，React 的调度器会执行这个任务，进入 performHydrationWork。
这个函数会遍历 Fiber 树，逐个节点进行注水。
function performHydrationWork(
current,
workInProgress,
lanes,
renderLanes,
subtreeLanes
) {
// 1. 获取当前节点的 DOM 节点（从 HTML 中解析出来的真实 DOM）
const domSibling = getNextHydratableSibling(workInProgress.stateNode);
// 2. 核心判断：是直接复用 DOM，还是卸载重挂？
if (domSibling === null) {
// 情况 A：DOM 节点缺失（比如服务端少写了这个标签）
// 这是一个“不匹配”。必须卸载当前节点及其子树，重新渲染
// 这是一个昂贵的操作，React 会打印警告
throw new Error('Node mismatch');
} else {
// 情况 B：DOM 节点存在，匹配上了！
// 开始递归处理子节点
reconcileChildren(
workInProgress,
current,
domSibling,
renderLanes
);
}
}渐进式体现在哪里？
体现在 reconcileChildren 的调用上。React 并不是一次性把整个树都注水完。
假设你的页面有 100 个节点。React 的调度器可能只注水了前 10 个节点（比如 Header 和 Logo），然后它就“停”了。
为什么停？因为调度器的时间片用完了，或者有更高优先级的任务（比如用户滚动页面）进来了。
此时，页面上只显示了 10 个节点，剩下的 90 个节点还是裸奔的 HTML。但是，这 10 个节点是可以交互的！ 用户可以点击 Header，按钮可以响应，输入框可以输入。
这就是渐进式注水。它把“全量注水”拆解成了“部分注水”，保证了核心交互区域的即时响应。
第六章：revalidate（重新验证）—— 被迫营业的注水
这是并发模式下注水最精彩的部分。还记得我们之前说的 Lane 吗？
当一个节点已经注水成功后，如果用户在这个节点上进行了交互（比如点击了按钮），React 会发生什么？
React 会给这个更新分配一个高优先级 Lane（比如 ActionLane）。然后，它会调用 revalidate 函数。
function revalidate(root, lane) {
// 1. 将这个更新标记为“需要注水”
// 这意味着：虽然这个更新逻辑已经跑完了，但它的 HTML 可能还没注水，或者需要重新注水
root.pendingLanes |= lane;
// 2. 强制调度一个同步渲染（或者高优先级并发渲染）
// 注意：这里传入的是 lane，而不是 hydrationLane
// 这会触发 React 的调度器，把刚才用户点击的任务再次加入队列
renderRootConcurrent(root, lane);
// 3. 在渲染完成后，再次检查是否需要注水
// 如果发现该节点还没注水，或者注水状态不一致，就重新执行注水逻辑
// 这就是“重新验证”的含义。
}场景还原：
- 页面加载，React 开始注水。只注水了头部。
- 用户点击了底部的“提交”按钮。
- React 检测到点击，分配
ActionLane。 - React 发现，“提交”按钮对应的 DOM 节点还没有注水（或者注水状态不对）。
- React 暂停当前的低优先级注水任务。
- React 启动高优先级渲染，处理“提交”按钮的逻辑。
- 渲染完成后，React 再次调用
scheduleHydrationWork，专门针对“提交”按钮这个节点进行注水。
看懂了吗？ 用户点击 -> 高优先级任务抢占 -> 注水任务被挤到一边 -> 任务完成后 -> 回头给没注水的节点注水。
这种机制保证了用户体验的流畅性：你永远感觉不到注水的存在，因为注水总是发生在你交互的“间隙”里。
第七章：代码实战 —— 模拟一个注水过程
为了让大家更直观地感受，我们来手写一个简化的 Hydrator 类，模拟这个过程。
class Hydrator {
constructor(htmlContent) {
this.nodes = this.parseHTML(htmlContent);
this.hydratedNodes = new Set();
this.pendingLanes = 0;
}
// 模拟 Lane 调度
scheduleHydration(lanes) {
console.log(`[Hydrator] 接收任务，优先级 Lane: ${lanes}`);
// 模拟 pickHydrationLane：如果用户输入，我们就不注水
if (lanes.includes('Input')) {
console.log(`[Hydrator] ⚠️ 用户正在输入，暂停注水！`);
return;
}
// 开始注水
this.hydrate();
}
hydrate() {
if (this.hydratedNodes.size === this.nodes.length) {
console.log(`[Hydrator] ✅ 所有节点已注水完毕。`);
return;
}
// 渐进式：只注水第一个没注水的节点
const nextNode = this.nodes.find(n => !this.hydratedNodes.has(n));
if (nextNode) {
this.hydratedNodes.add(nextNode);
console.log(`[Hydrator] 🚰 正在注水节点: ${nextNode}`);
// 模拟注水耗时
setTimeout(() => {
this.hydrate(); // 继续注水下一个
}, 100);
}
}
// 模拟用户交互
handleInput() {
const inputLane = ['Input'];
this.scheduleHydration(inputLane);
}
// 模拟点击
handleClick() {
const clickLane = ['Action'];
this.scheduleHydration(clickLane);
}
parseHTML(str) {
// 简单模拟
return str.split(' ').filter(Boolean);
}
}
// 初始化
const html = "Header Footer Button Input";
const hydrator = new Hydrator(html);
// 模拟页面加载
console.log("--- 开始加载 ---");
hydrator.hydrate(); // 节点1
// 模拟用户输入
setTimeout(() => {
console.log("--- 用户输入 ---");
hydrator.handleInput(); // 节点2暂停
}, 150);
// 模拟用户点击
setTimeout(() => {
console.log("--- 用户点击 ---");
hydrator.handleClick(); // 节点3注水，节点4暂停
}, 350);运行结果预览：
--- 开始加载 ---
[Hydrator] 🚰 正在注水节点: Header
[Hydrator] 🚰 正在注水节点: Footer
--- 用户输入 ---
[Hydrator] 接收任务，优先级 Lane: Input
[Hydrator] ⚠️ 用户正在输入，暂停注水！
--- 用户点击 ---
[Hydrator] 接收任务，优先级 Lane: Action
[Hydrator] 🚰 正在注水节点: Button在这个小 Demo 里，我们看到了 Lane 的作用：它就像一个交通警察，指挥着注水车什么时候走，什么时候停。
第八章：源码深挖 —— requestHydrationCallback 与 时间切片
在 React 源码中，requestHydrationCallback 是连接 Fiber 树和 Lane 调度器的桥梁。
function requestHydrationCallback(root) {
return function onHydrationDrain() {
// 当调度器从 Fiber 树的某个点“抽离”出来时，调用这个函数
// 这意味着：当前的渲染任务可能被中断了
// React 会检查是否还有未完成的注水任务
// 如果有，且优先级足够高，就继续注水
if (root.hydrationState.isPending) {
// 检查当前剩余的 lanes
// 如果还有 HydrationLane，就继续调度
const remainingLanes = root.pendingLanes;
if (remainingLanes !== NoLanes) {
scheduleHydrationWork(root, remainingLanes);
} else {
// 如果没有剩余任务，标记为完成
root.hydrationState.isPending = false;
}
}
};
}这个机制配合 React 的 时间切片，实现了真正的渐进式。
React 的渲染循环是这样的：
- 开始渲染 ->
renderRootConcurrent。 - 渲染一个节点 ->
performHydrationWork。 - 如果时间片用完了 ->
requestHydrationCallback被调用。 requestHydrationCallback通知调度器：“我不干了，我要去休息了”。- 调度器检查：有用户输入吗？有！那就把 CPU 让给用户输入。
- 用户输入处理完毕，时间片再次到来。调度器回到
renderRootConcurrent。 - 从上次中断的地方继续 -> 继续注水下一个节点。
第九章：处理不匹配 —— 最昂贵的操作
虽然并发模式让注水变得平滑，但有一个问题始终存在：服务端渲染的 HTML 和客户端的 JS 逻辑不一致。
比如，服务端渲染了 <div id="app">Hello</div>，但客户端 JS 运行后发现应该渲染 <div id="app">Goodbye</div>。
这时候，React 会怎么做？
在 performHydrationWork 中，如果发现 domSibling 不匹配（比如 getNextHydratableSibling 返回了 null，或者类型不对），React 会抛出一个 Hydration Mismatch。
function performHydrationWork(...) {
// ...
if (domSibling === null) {
// 不匹配！
// 标记这个节点为 "shouldRetry" 或者直接卸载
// 卸载意味着：把这个节点从 DOM 中移除，然后重新挂载（重新渲染）
// 这是一个非常重的操作，因为涉及到 DOM 的增删改查
// React 在源码中会使用 throw new Error() 来中断当前的同步渲染流
// 然后重新进入并发渲染模式，不带 Hydration 状态，直接走完全量渲染
throw new Error('Hydration failed because the initial UI does not match what was rendered on the server.');
}
}并发模式如何缓解这个问题？
并发模式通过“快速失败”和“后台重试”来缓解。
- 快速失败： 如果在注水过程中发现不匹配，React 会立即停止注水，并标记整个根节点为“需要重新渲染”。
- 后台重试： React 不会立刻崩溃，而是会进入一个“降级模式”。它可能会在后台继续处理其他高优先级的更新，直到用户不再交互。
- 降级渲染： 最终，React 会放弃注水，直接运行一次完整的、不带 Hydration 状态的
render。虽然这会丢失 SSR 的即时渲染优势（白屏时间变长），但它保证了功能的正确性。
第十章：进阶话题 —— Offscreen（离屏）与 Hydration
最后，我们稍微提一下 Offscreen。这是一个非常高级的 API，它允许 React 在后台渲染组件，而不影响当前页面的交互。
在并发模式下，Offscreen Container 的 Hydration 是一个巨大的挑战。
如果一个页面有两个标签页，一个在前台，一个在后台。前台页面需要响应点击。后台页面正在 Hydration。
React 会如何调度？
答案依然是 Lane。后台页面的 Hydration 任务会被分配到 OffscreenLane（一个极低优先级的 Lane）。它只能在用户不操作前台页面的情况下进行。
这就像你在开车（前台页面），导航（后台 Hydration）在后台运行。如果你突然踩刹车（用户交互），导航会立刻暂停，等你踩油门（恢复渲染），导航再继续。
结语：优雅的艺术
好了，各位听众，我们的源码探险之旅接近尾声。
React 的并发模式注水，本质上是一场关于资源分配的艺术。它不再是一个笨拙的“先全部渲染，再全部注水”的流程，而是一个聪明的、有优先级的、能够感知用户意图的动态过程。
通过 Lane（车道） 优先级系统，React 精准地控制了注水的节奏。高优先级的交互任务插队，低优先级的注水任务等待或降级。这种机制保证了用户体验的极致流畅——你感觉不到注水的存在，因为注水总是在你不知不觉中悄然完成，或者在你需要的时候被迅速响应。
总结一下关键点：
- HydrationState 是注水的状态机。
- Lane 是指挥棒，决定了注水任务的生死。
- scheduleHydrationWork 决定了注水何时开始。
- requestHydrationCallback 决定了注水何时中断。
- 渐进式意味着：先注水核心，再注水边缘；先注水可见，再注水不可见。
希望这篇文章能让你对 React 18 的并发模式有更深层次的理解。下次当你写 hydrateRoot 的时候，不妨想象一下，你的代码里正有一群微小的 React 员工，在高速公路上，为了让你点击按钮的那一刻能立刻响应，正小心翼翼地避让着每一辆飞驰而来的“用户输入”卡车。
谢谢大家，我是你们的资深编程专家，我们下节课再见！记得给代码点赞！