第 25 章
Reconciler 与 Diff 算法源码解析
第25章：Reconciler 与 Diff 算法源码解析
理解协调器就是理解 React 如何用最小代价把虚拟 DOM 的变化同步到真实 DOM。
本章核心问题：React 的 Diff 算法基于哪三条规则？多子节点的两轮遍历策略如何工作？ 读完本章你将理解：
- 类型不同直接销毁重建、相同类型 DOM 节点只更新属性、相同类型组件更新 props 后继续渲染
- 多子节点使用两轮遍历：第一轮顺序比较，第二轮通过 Map 处理乱序
- placeChild 算法的'将末尾移到开头'性能陷阱是 key 不应使用数组下标的根本原因
Level 1 · 你需要知道的（1-3年经验）
协调器的入口：reconcileChildFibers
每次 beginWork 处理一个 Fiber 节点时，如果需要处理该节点的子元素，就会调用 reconcileChildFibers（更新场景）或 mountChildFibers（首次挂载场景）。这两个函数实际上是同一个工厂函数的两个实例：
// packages/react-reconciler/src/ReactFiberReconciler.js
// 两个函数来自同一工厂，唯一区别是 shouldTrackSideEffects 参数
export const reconcileChildFibers = createChildReconciler(true);
export const mountChildFibers = createChildReconciler(false);
shouldTrackSideEffects 这个参数至关重要。当它为 true（更新场景）时，协调器会在 Fiber 节点上标记 Placement（需要插入）、Deletion（需要删除）等副作用 flags。当它为 false（首次挂载）时，不标记这些 flags——因为首次挂载时整棵树都是新的，React 会在最终提交时统一将根节点插入 DOM，无需逐一标记每个节点。
// packages/react-reconciler/src/ReactChildFiber.js（简化）
function createChildReconciler(shouldTrackSideEffects) {
function placeSingleChild(newFiber) {
// 只有在追踪副作用且该节点是新建的（没有 alternate）时才标记 Placement
if (shouldTrackSideEffects && newFiber.alternate === null) {
newFiber.flags |= Placement;
}
return newFiber;
}
function deleteChild(returnFiber, childToDelete) {
if (!shouldTrackSideEffects) return;
// 将需要删除的节点加入父节点的 deletions 列表
const deletions = returnFiber.deletions;
if (deletions === null) {
returnFiber.deletions = [childToDelete];
returnFiber.flags |= ChildDeletion;
} else {
deletions.push(childToDelete);
}
}
// ... 其他辅助函数
function reconcileChildFibers(returnFiber, currentFirstChild, newChild, lanes) {
// 这里是核心分发逻辑
// 根据 newChild 的类型分发到不同的处理函数
}
return reconcileChildFibers;
}
Diff 的三条核心规则
React 的 Diff 算法建立在三条规则之上。这三条规则不是凭空而来，而是 React 团队基于 Web 应用实际使用模式做出的工程决策：
规则一：类型不同，直接销毁重建
如果新旧节点的类型（type）不同，React 不会尝试复用，直接删除旧节点及其整个子树，从头创建新节点。
// beginWork 中的类型比较（简化）
function updateElement(returnFiber, current, element, lanes) {
const elementType = element.type;
if (current !== null) {
if (current.elementType === elementType) {
// 类型相同，复用
const existing = useFiber(current, element.props);
existing.ref = coerceRef(returnFiber, current, element);
existing.return = returnFiber;
return existing;
}
// 类型不同：current 会被加入 deletions，新建 Fiber
}
// 创建全新节点
const created = createFiberFromElement(element, returnFiber.mode, lanes);
created.ref = coerceRef(returnFiber, current, element);
created.return = returnFiber;
return created;
}
为什么不尝试"智能地"复用不同类型的节点？因为当类型改变时（比如从 <div> 变成 <section>，或从 ComponentA 变成 ComponentB），其内部状态已经完全无效，强行复用只会带来状态污染和难以排查的 bug，不如直接重建来得干净。
规则二：相同类型的 DOM 节点，只更新属性
当同一位置的新旧节点类型相同（例如都是 <input type="text">），React 会复用现有的 DOM 节点，只更新发生变化的属性。
// packages/react-reconciler/src/ReactFiberCompleteWork.js（简化）
function updateHostComponent(current, workInProgress, type, newProps) {
const oldProps = current.memoizedProps;
if (oldProps === newProps) {
// props 引用相同（memo 场景），无需更新
return;
}
// 比较新旧 props，生成需要更新的属性列表
const updatePayload = prepareUpdate(
current.stateNode, // 真实 DOM 节点
type,
oldProps,
newProps,
);
// 将更新载荷保存到 work-in-progress 节点上
// 提交阶段会使用这个载荷来更新真实 DOM
workInProgress.updateQueue = updatePayload;
if (updatePayload) {
markUpdate(workInProgress);
}
}
prepareUpdate 会遍历新旧 props，找出差异。对于事件监听器，它通过 on 前缀识别，在更新时替换处理函数。对于 style，它会深入比较样式对象的每个属性。
规则三：相同类型的组件，更新 props 后继续渲染
对于相同类型的组件（函数组件或类组件），React 复用现有 Fiber 节点，将新的 props 传入组件，重新执行渲染。
// packages/react-reconciler/src/ReactFiberBeginWork.js（简化）
function updateFunctionComponent(current, workInProgress, Component, nextProps, renderLanes) {
// 调用函数组件本身，传入新 props
let nextChildren = renderWithHooks(
current,
workInProgress,
Component,
nextProps,
context,
renderLanes,
);
// 协调子元素
reconcileChildren(current, workInProgress, nextChildren, renderLanes);
return workInProgress.child;
}
Level 2 · 它是怎么运行的（3-5年经验）
单子节点的协调
当新的子元素只有一个时，协调逻辑相对简单：
// packages/react-reconciler/src/ReactChildFiber.js（简化）
function reconcileSingleElement(returnFiber, currentFirstChild, element, lanes) {
const key = element.key;
let child = currentFirstChild;
// 遍历现有子节点链表，寻找可复用的节点
while (child !== null) {
if (child.key === key) {
const elementType = element.type;
if (child.tag === Fragment ? element.type === REACT_FRAGMENT_TYPE
: child.elementType === elementType) {
// key 和 type 都匹配，复用这个节点
// 删除其他所有兄弟节点
deleteRemainingChildren(returnFiber, child.sibling);
const existing = useFiber(child, element.props);
existing.return = returnFiber;
return existing;
}
// key 匹配但 type 不匹配，删除当前及所有后续节点
deleteRemainingChildren(returnFiber, child);
break;
} else {
// key 不匹配，删除当前节点，继续找
deleteChild(returnFiber, child);
}
child = child.sibling;
}
// 没找到可复用的，创建新节点
const created = createFiberFromElement(element, returnFiber.mode, lanes);
created.return = returnFiber;
return created;
}
这里有个细节值得注意：当找到 key 匹配但 type 不匹配的节点时，React 立即调用 deleteRemainingChildren（删除当前节点及所有后续兄弟），然后 break 出循环——因为根据 Diff 规则一，类型不同就必须重建，并且已知后面的节点 key 都不会再匹配（key 在同级中唯一），所以不需要继续查找。
多子节点的协调：两轮遍历算法
列表 Diff 是协调算法中最复杂的部分。当新子元素是一个数组时，React 使用两轮遍历策略：
// packages/react-reconciler/src/ReactChildFiber.js（核心逻辑简化）
function reconcileChildrenArray(returnFiber, currentFirstChild, newChildren, lanes) {
let resultingFirstChild = null; // 新链表的第一个节点
let previousNewFiber = null; // 上一个处理的新节点
let oldFiber = currentFirstChild; // 当前旧节点指针
let lastPlacedIndex = 0; // 上次 DOM 中已确定位置的节点索引
let newIdx = 0; // 新数组的当前索引
let nextOldFiber = null;
// ===== 第一轮：顺序比较，遇到 key 不匹配就停止 =====
for (; oldFiber !== null && newIdx < newChildren.length; newIdx++) {
if (oldFiber.index > newIdx) {
nextOldFiber = oldFiber;
oldFiber = null;
} else {
nextOldFiber = oldFiber.sibling;
}
// 尝试复用旧节点
const newFiber = updateSlot(returnFiber, oldFiber, newChildren[newIdx], lanes);
if (newFiber === null) {
// key 不匹配，停止第一轮
if (oldFiber === null) oldFiber = nextOldFiber;
break;
}
if (shouldTrackSideEffects) {
if (oldFiber && newFiber.alternate === null) {
// 使用了不同的旧节点，需要删除原旧节点
deleteChild(returnFiber, oldFiber);
}
}
lastPlacedIndex = placeChild(newFiber, lastPlacedIndex, newIdx);
// ... 构建新链表
oldFiber = nextOldFiber;
}
// 处理第一轮结束后的剩余情况
if (newIdx === newChildren.length) {
// 新元素已处理完，删除剩余旧节点
deleteRemainingChildren(returnFiber, oldFiber);
return resultingFirstChild;
}
if (oldFiber === null) {
// 旧节点已处理完，剩余新元素全部新建
for (; newIdx < newChildren.length; newIdx++) {
const newFiber = createChild(returnFiber, newChildren[newIdx], lanes);
// ... 加入新链表
}
return resultingFirstChild;
}
// ===== 第二轮：乱序处理 =====
// 将剩余旧节点放入 Map，以 key（或 index）为键
const existingChildren = mapRemainingChildren(returnFiber, oldFiber);
for (; newIdx < newChildren.length; newIdx++) {
const newFiber = updateFromMap(existingChildren, returnFiber, newIdx, newChildren[newIdx], lanes);
if (newFiber !== null) {
if (shouldTrackSideEffects) {
if (newFiber.alternate !== null) {
// 从 Map 中复用了旧节点，从 Map 删除避免被误删
existingChildren.delete(newFiber.key === null ? newIdx : newFiber.key);
}
}
lastPlacedIndex = placeChild(newFiber, lastPlacedIndex, newIdx);
}
}
if (shouldTrackSideEffects) {
// Map 中剩余的旧节点都没有对应的新节点，全部删除
existingChildren.forEach(child => deleteChild(returnFiber, child));
}
return resultingFirstChild;
}
placeChild：最小移动算法
第二轮遍历的 placeChild 函数决定了节点是否需要移动：
function placeChild(newFiber, lastPlacedIndex, newIndex) {
newFiber.index = newIndex;
if (!shouldTrackSideEffects) return lastPlacedIndex;
const current = newFiber.alternate;
if (current !== null) {
// 这是一个复用的节点，检查它在旧列表中的位置
const oldIndex = current.index;
if (oldIndex < lastPlacedIndex) {
// 旧位置在已稳定节点的左边，需要向右移动
newFiber.flags |= Placement;
return lastPlacedIndex;
} else {
// 旧位置在已稳定节点的右边，不需要移动
return oldIndex;
}
} else {
// 新建节点，需要插入
newFiber.flags |= Placement;
return lastPlacedIndex;
}
}
这个算法有一个著名的性能陷阱：将最后一个节点移到第一个。例如 [A, B, C, D] 变成 [D, A, B, C]，算法会移动 A、B、C 三次而不是移动 D 一次，因为 D 的旧 index（3）大于所有其他节点，算法认为 A、B、C 都需要向右移动。这就是为什么 key 不应该使用数组下标——当列表顺序发生变化时，下标作为 key 会导致大量无效的 DOM 操作。
Level 3 · 规范怎么定义的（资深）
React 19 的协调优化
React 19 在协调算法层面引入了几项优化。其中之一是对 subtreeFlags 的提前判断：如果子树的 subtreeFlags 和 childLanes 都为 0，说明子树完全没有变化，可以直接跳过该子树的协调。
// React 19 中 beginWork 的早期退出优化
function beginWork(current, workInProgress, renderLanes) {
if (current !== null) {
const oldProps = current.memoizedProps;
const newProps = workInProgress.pendingProps;
if (oldProps !== newProps || hasLegacyContextChanged()) {
didReceiveUpdate = true;
} else {
// props 未变化，检查是否有待处理的工作
const hasScheduledUpdateOrContext = checkScheduledUpdateOrContext(current, renderLanes);
if (!hasScheduledUpdateOrContext) {
didReceiveUpdate = false;
// 直接复用，跳过协调
return attemptEarlyBailoutIfNoScheduledUpdate(current, workInProgress, renderLanes);
}
}
}
// ...
}
协调器是 React 性能优化的核心战场。理解它的工作原理，不只是满足技术好奇心，更是写出高性能 React 代码的基础：正确使用 key，避免不必要的类型改变，合理组织组件层次，都是基于对协调算法的深层理解。
Level 4 · 边界与陷阱（所有人）
生产环境常见问题
在实际项目中，本章涵盖的概念最常见的问题包括：
-
忽视边界条件：在正常路径下工作正常的代码，在异常路径（网络失败、用户快速操作、组件卸载）下可能产生 bug。始终考虑清理和取消逻辑。
-
过早优化：在没有测量的情况下添加优化代码，增加了复杂度但不一定提升性能。先用 Profiler 确认问题存在，再实施优化。
-
文档与实际行为的差异：React 的行为在不同版本间可能有微妙差异，尤其是并发模式相关的特性。始终以实际测试结果为准。