Vue 3 设计与实现
第 11 章 虚拟 DOM 与 Diff 算法
第 11 章 虚拟 DOM 与 Diff 算法
本章要点
- 虚拟 DOM 的本质：从 VNode 的数据结构到它如何成为 UI 的中间表示层
- VNode 的类型系统：ShapeFlag 位掩码如何用一个整数编码所有节点类型信息
- patch 函数的分发逻辑：如何根据 VNode 类型选择不同的处理路径
- 子节点 Diff 的核心算法：双端比较、最长递增子序列、key 的关键作用
- Block Tree 与 PatchFlag：编译时优化如何让 Diff 从 O(n) 降到 O(动态节点数)
- Fragment、Teleport、Suspense 等特殊 VNode 的处理策略
- Vue 3.6 Vapor Mode 对传统 VNode 体系的挑战与共存
在前面的章节中，我们已经深入了编译器和组件系统。编译器将模板转化为渲染函数，组件系统管理每个组件的生命和状态。但在这两者之间，还有一个至关重要的中间层——虚拟 DOM。
当渲染函数执行时，它不会直接操作真实 DOM，而是生成一棵由 JavaScript 对象构成的虚拟节点树。当组件状态变化时，新的虚拟树与旧的虚拟树进行对比——这个过程就是 Diff。Diff 的结果是一组最小化的 DOM 操作指令，精确地把界面从旧状态更新到新状态。
为什么需要虚拟 DOM
多数人把虚拟 DOM 讲成”JavaScript 操作 DOM 慢，我们在内存里先算好 diff 再动 DOM”——这其实不是重点，甚至有点误导。
真正的原因要从一致性说起。浏览器 DOM 是状态机：你每次调 element.textContent = "..." 都是对世界的一次有状态改动。当 UI 复杂到上百个节点、上千次改动交错发生时，“正确地按顺序改对每一个节点”本身就是难题——一个节点漏改、一个顺序错、一个旧引用没释放，都会导致界面闪烁、内存泄漏或逻辑错误。
声明式框架把这个问题倒转了：你不再告诉框架”先改 A 再改 B 最后改 C”，而是直接写”现在 UI 看起来应该是这样”。框架的任务是拿到新旧两个描述，自动计算出最小的改动序列。这里的”描述”必须是纯数据结构——如果你直接用真实 DOM 作为描述（拿旧 DOM 和新 DOM 对比），每一次对比都要读 DOM（又慢又有副作用）、每一次计算都可能被浏览器重排扰动。虚拟 DOM 是纯 JS 对象：它的创建是零副作用的内存分配、它的遍历是普通对象遍历、它的生命周期完全由 GC 管。这才是 VDOM 存在的根本理由——让”描述”和”执行”分层，让 diff 算法能在纯函数语境下工作。
这个思想贯穿很多现代框架。React 早期论文《React: Rethinking Best Practices》里 Pete Hunt 就提过：直接操作 DOM 的问题不是慢，而是”难以推理”（hard to reason about）。VDOM 让 UI 描述变成纯函数的输出，任何一次 UI 变化都是 UI = f(state) 的重新执行。这是从命令式到声明式的关键抽象。
当然 VDOM 也不是银弹。它有两个代价：描述一套、执行一套，理论上比直接操作慢两次遍历；以及每次更新都要分配一堆新 VNode 对象，给 GC 增加压力。Vue 3 从 Block Tree 到静态提升到最终 Vapor Mode 的一整条优化链，都是在针对这两个代价。本章后面会详细展开。
这一章，我们要完全拆解这个过程——从 VNode 的数据结构到 Diff 的五步算法，再到 Vue 3 在编译期做的一系列”让运行时少干活”的优化。
11.1 VNode：虚拟 DOM 的原子
VNode 的数据结构
每一个虚拟节点都是一个 VNode 对象。它的结构远比”一个标签名加一堆属性”复杂得多：
// packages/runtime-core/src/vnode.ts
export interface VNode<
HostNode = RendererNode,
HostElement = RendererElement,
ExtraProps = { [key: string]: any }
> {
__v_isVNode: true // VNode 标记
type: VNodeTypes // 节点类型：string | Component | Fragment | ...
props: (VNodeProps & ExtraProps) | null
key: string | number | symbol | null // Diff 的身份标识
ref: VNodeNormalizedRef | null // 模板 ref
children: VNodeNormalizedChildren // 子节点
// ---- 运行时状态 ----
el: HostNode | null // 对应的真实 DOM 节点
anchor: HostNode | null // Fragment 的锚点
component: ComponentInternalInstance | null // 组件实例引用
// ---- 优化标记 ----
shapeFlag: number // 节点形状位掩码
patchFlag: number // 编译器标记的动态类型
dynamicProps: string[] | null // 动态属性名列表
dynamicChildren: VNode[] | null // Block 收集的动态子节点
// ---- 其他 ----
dirs: DirectiveBinding[] | null // 指令绑定
transition: TransitionHooks | null
suspense: SuspenseBoundary | null
appContext: AppContext | null
}一个 VNode 既是 UI 的描述，又携带了优化信息，还反向引用了真实 DOM。它是连接”声明式意图”和”命令式操作”的桥梁。
为什么 VNode 的字段这么多
乍一看 VNode 接口有近 20 个字段，显得臃肿。但每一个字段都是”关键路径上必须要有”的——缺哪一个都会破坏某个功能。
__v_isVNode是一个显式的类型标记。JS 没有 nominal type 系统，依赖运行时 duck typing。Vue 需要能在 slot、children 里区分”这是一个 VNode”还是”这是一个普通对象”——专门标记一个 symbol/boolean 字段是最稳妥的方式。el反向引用真实 DOM，是为了 Diff 能原地复用 DOM 节点而不是销毁重建。如果 VNode 不持有对应的 DOM 引用，每次 diff 都要从父节点重新查找子节点位置，复杂度陡增。component把 VNode 和组件实例关联起来。一个组件 VNode（type是组件对象）只是一个”声明”，它对应的实际组件实例（ComponentInternalInstance）是另一个概念。二者通过component字段连接，让 parent 的 diff 能够”顺藤摸瓜”找到子组件实例做更新。shapeFlag是类型的位编码，已经讲过。patchFlag是编译器塞给运行时的”这个节点哪些部分可能变化”的提示——后面 Block Tree 一节详细讲。dynamicChildren是 Block 收集的动态子节点列表——它让运行时可以绕过静态子节点、只 diff 真正变化的部分。dirs、transition、suspense是给指令系统、过渡动画、异步边界用的——每个特性都需要在 VNode 上挂自己的元数据。
这种”节点对象承载所有上下文”的设计有个代价：VNode 对象比想象中大。Vue 团队在 3.2 版本做过统计，一个典型组件的 VNode 平均大小约 600 字节，包含大量空字段。为此 Vapor Mode（3.6+）探索了一个完全不同的模型：根本不创建 VNode 对象，直接生成命令式更新代码——后面会提到。
从 Vue 2 到 Vue 3 的 VNode 进化
Vue 2 的 VNode 已经是 VDOM 节点，但 Vue 3 在它之上做了两个关键扩展。一是扁平化 children：Vue 2 的文本子节点和元素子节点混在一起，需要遍历判断类型；Vue 3 通过 ShapeFlag 提前标记 TEXT_CHILDREN / ARRAY_CHILDREN，分发逻辑变成常数时间。二是patchFlag——这个字段 Vue 2 没有，它让编译器能把”这个节点的 class 可能变”之类的微粒度信息带到运行时，作为精确 diff 的依据。这两个进化在下面的 Block Tree 一节里共同发挥作用。
ShapeFlag：用位运算编码节点类型
Vue 使用一个整数的不同位来标记 VNode 的类型信息，这是一种经典的位掩码模式：
// packages/shared/src/shapeFlags.ts
export enum ShapeFlags {
ELEMENT = 1, // 0000 0001 — 普通 HTML 元素
FUNCTIONAL_COMPONENT = 1 << 1, // 0000 0010 — 函数式组件
STATEFUL_COMPONENT = 1 << 2, // 0000 0100 — 有状态组件
TEXT_CHILDREN = 1 << 3, // 0000 1000 — 子节点是文本
ARRAY_CHILDREN = 1 << 4, // 0001 0000 — 子节点是数组
SLOTS_CHILDREN = 1 << 5, // 0010 0000 — 子节点是插槽
TELEPORT = 1 << 6, // 0100 0000 — Teleport 组件
SUSPENSE = 1 << 7, // 1000 0000 — Suspense 组件
COMPONENT_SHOULD_KEEP_ALIVE = 1 << 8,
COMPONENT_KEPT_ALIVE = 1 << 9,
COMPONENT = ShapeFlags.STATEFUL_COMPONENT | ShapeFlags.FUNCTIONAL_COMPONENT
}为什么用位掩码而不是字符串枚举？因为位运算的判断只需要一条 CPU 指令：
// 判断是否是元素
if (shapeFlag & ShapeFlags.ELEMENT) { /* ... */ }
// 判断是否是组件且有数组子节点
if (shapeFlag & ShapeFlags.COMPONENT && shapeFlag & ShapeFlags.ARRAY_CHILDREN) { /* ... */ }
// 创建时组合标记
const shapeFlag = ShapeFlags.ELEMENT | ShapeFlags.ARRAY_CHILDREN在 Diff 的热路径上，每一个 if 判断都被执行成千上万次。位运算比字符串比较快一个数量级，这是框架级性能优化的典型手法。
从类型字符串到位掩码的思维转移
很多人写业务代码习惯了 type === 'component' 这种字符串判断——清晰、自解释、IDE 容易高亮。但到了框架底层就不一样了。
位掩码编码的本质是把”类型”变成可以多维组合的集合成员。一个 VNode 可以同时”是元素”（ELEMENT）并且”有数组子节点”（ARRAY_CHILDREN）并且”有 transition 指令”——如果用字符串枚举，要么搞 'element+array+transition' 这种笛卡尔积爆炸的字符串，要么就用多个字段分开存。位掩码让这些正交维度合并在一个 32 位整数里——理论上可以编码 32 个独立维度，用 | 组合、用 & 判断，常数时间完成。
从工程视角看，这种设计还有个容易忽视的好处：整数比较是无分配的。字符串比较在 V8 里虽然也很快（有字符串驻留），但涉及到跨页面对象（比如 iframe）、或者字符串本身是动态拼接的，就会产生临时对象、触发 GC。位运算永远在 SMI（小整数）上跑，没有内存分配。Vue 之所以敢在 render 热路径上放心用 shapeFlag 检查——就是因为它物理上就不可能产生任何 GC 压力。
这种”用位编码替代语义字符串”的手法在性能敏感领域很常见。丛书卷《React 19 源码解读》第 6 章讲 Fiber 节点时也讲过——React 的 Fiber.flags 字段是完全一样的设计思路（Placement、Update、Deletion 等用位编码），ReactFiberFlags.js 里定义了 20 多个位。再向底层看，V8 引擎内部表示对象 shape 的 HiddenClass、Linux 内核表示进程状态的 task_struct.flags，都是同一个模式。理解这种”多维度类型合并到一个整数”的抽象，是跨越多个层次阅读系统源码时反复获益的能力。
createVNode：VNode 的工厂
渲染函数中的 h() 最终调用 createVNode 来创建 VNode：
// packages/runtime-core/src/vnode.ts（简化）
export function createVNode(
type: VNodeTypes,
props: (Data & VNodeProps) | null = null,
children: unknown = null,
patchFlag: number = 0,
dynamicProps: string[] | null = null,
isBlockNode = false
): VNode {
// 1. 规范化 type
if (isVNode(type)) {
// 克隆已有 VNode
return cloneVNode(type, props)
}
// 2. 类组件规范化
if (isClassComponent(type)) {
type = type.__vccOpts
}
// 3. 规范化 props（class、style 合并）
if (props) {
props = guardReactiveProps(props)
let { class: klass, style } = props
if (klass && !isString(klass)) {
props.class = normalizeClass(klass)
}
if (isObject(style)) {
props.style = normalizeStyle(style)
}
}
// 4. 计算 shapeFlag
const shapeFlag = isString(type)
? ShapeFlags.ELEMENT
: isSuspense(type)
? ShapeFlags.SUSPENSE
: isTeleport(type)
? ShapeFlags.TELEPORT
: isObject(type)
? ShapeFlags.STATEFUL_COMPONENT
: isFunction(type)
? ShapeFlags.FUNCTIONAL_COMPONENT
: 0
// 5. 创建 VNode 对象
return createBaseVNode(type, props, children, patchFlag, dynamicProps, shapeFlag, isBlockNode)
}注意 patchFlag 和 dynamicProps 参数——它们由编译器注入，运行时不会自己去分析哪些属性是动态的。这就是 Vue 3 的编译-运行时协作模型。
11.2 patch：万物的入口
整个运行时 Diff 的主循环就一个函数——patch。理解 patch 是理解 Vue diff 的先决条件：所有 DOM 更新、所有子组件递归、所有的增/删/改分发，都从这个函数出发。把它的 switch-case 看懂，后面每一节都是在讲 switch 的某一个 case 里具体怎么做。
patch 函数的分发逻辑
patch 是整个渲染器的核心入口。无论是首次渲染还是更新，都从 patch 开始：
// packages/runtime-core/src/renderer.ts（简化）
const patch: PatchFn = (
n1, // 旧 VNode（null 表示首次挂载）
n2, // 新 VNode
container, // DOM 容器
anchor = null,
parentComponent = null,
parentSuspense = null,
namespace = undefined,
slotScopeIds = null,
optimized = false
) => {
// 1. 如果新旧节点类型完全不同，直接卸载旧的
if (n1 && !isSameVNodeType(n1, n2)) {
anchor = getNextHostNode(n1)
unmount(n1, parentComponent, parentSuspense, true)
n1 = null // 重置为 null，后续走挂载逻辑
}
// 2. 如果新节点标记为 BAIL，关闭优化
if (n2.patchFlag === PatchFlags.BAIL) {
optimized = false
n2.dynamicChildren = null
}
// 3. 根据类型分发
const { type, ref, shapeFlag } = n2
switch (type) {
case Text:
processText(n1, n2, container, anchor)
break
case Comment:
processCommentNode(n1, n2, container, anchor)
break
case Static:
if (n1 == null) {
mountStaticNode(n2, container, anchor, namespace)
}
break
case Fragment:
processFragment(n1, n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
break
default:
if (shapeFlag & ShapeFlags.ELEMENT) {
processElement(n1, n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else if (shapeFlag & ShapeFlags.COMPONENT) {
processComponent(n1, n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else if (shapeFlag & ShapeFlags.TELEPORT) {
;(type as typeof TeleportImpl).process(n1, n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized, internals)
} else if (shapeFlag & ShapeFlags.SUSPENSE) {
;(type as typeof SuspenseImpl).process(n1, n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized, internals)
}
}
// 4. 设置 ref
if (ref != null && parentComponent) {
setRef(ref, n1 && n1.ref, parentSuspense, n2 || n1, !n2)
}
}这个函数的设计体现了一个重要原则：类型驱动的分发。不同类型的 VNode 走完全不同的处理路径，各自优化，互不干扰。
flowchart TD
A[patch] --> B{n1 与 n2 类型相同?}
B -->|否| C[卸载 n1, 挂载 n2]
B -->|是| D{VNode type}
D -->|Text| E[processText]
D -->|Comment| F[processCommentNode]
D -->|Static| G[mountStaticNode]
D -->|Fragment| H[processFragment]
D -->|Element| I[processElement]
D -->|Component| J[processComponent]
D -->|Teleport| K[Teleport.process]
D -->|Suspense| L[Suspense.process]
isSameVNodeType：身份判定
“两个 VNode 是不是同一个节点”——看似简单的问题，在有 key 和没 key 的情况下答案完全不同。Vue 的判定逻辑：type 相同且 key 相同。其中 key 默认是 null；没指定时只靠 type 判等。这也是”没 key 的列表更新退化为位置对比”的根因。
判断两个 VNode 是否”同一个”的逻辑极简：
export function isSameVNodeType(n1: VNode, n2: VNode): boolean {
return n1.type === n2.type && n1.key === n2.key
}两个条件——相同的类型，相同的 key。如果类型变了（比如从 <div> 变成 <span>），没有任何 Diff 的意义，直接替换。如果 key 变了，即使类型相同，也视为不同节点。这就是为什么 key 在列表渲染中如此重要。
11.3 元素的 Patch
普通 HTML 元素的 patch 是 diff 机制里最”不神秘”的一块——就是老实地比属性、老实地比子节点。但这里有几个容易忽视的细节值得单独说。
第一，属性 diff 不是深度比较。Vue 只做浅层对比——props.style === oldProps.style 就跳过。这要求用户写模板时避免每次重新生成新对象（例如每次 render 都新建 {color: 'red'}），否则 diff 会错误地判断”变了”。这个坑在 SFC 里不明显（模板里写 :style="styleObj" 一般是响应式引用），但在 render 函数或 JSX 里就常踩。
第二，class 和 style 在 patch 时有特殊路径。它们支持数组、对象、字符串多种形态，Vue 统一归一化后再应用。这段代码不长但分支很细，读完能看懂”为什么 :class="[a, b, {c: d}]" 这种花式写法能正常工作”。
第三，ref 的解析发生在 patch 后。当 VNode 的 ref 字段存在时，patch 结束后会把对应的 DOM 节点或组件实例挂到 ref 对象上——这是”ref.value 能拿到 DOM”的实现机制。如果你观察到 ref 绑的节点”第一次是 null 第二次才有”，就是因为 ref 的赋值发生在 patch 之后、mounted 钩子之前。
这些细节读 patchElement 和 mountElement 源码能一一印证。读完这三页代码，你会对”模板语法背后发生了什么”建立具象的感觉——再遇到 :class 不生效、ref 拿不到节点之类的问题，可以直接定位到源码的哪一行。
当 patch 分发到 processElement 时，会区分挂载和更新两条路径：
const processElement = (
n1: VNode | null,
n2: VNode,
container: RendererElement,
anchor: RendererNode | null,
parentComponent: ComponentInternalInstance | null,
parentSuspense: SuspenseBoundary | null,
namespace: ElementNamespace,
slotScopeIds: string[] | null,
optimized: boolean
) => {
if (n1 == null) {
mountElement(n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else {
patchElement(n1, n2, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
}
}patchElement：属性与子节点的更新
const patchElement = (
n1: VNode,
n2: VNode,
parentComponent: ComponentInternalInstance | null,
parentSuspense: SuspenseBoundary | null,
namespace: ElementNamespace,
slotScopeIds: string[] | null,
optimized: boolean
) => {
const el = (n2.el = n1.el!) // 复用真实 DOM 节点
const oldProps = n1.props || EMPTY_OBJ
const newProps = n2.props || EMPTY_OBJ
let { patchFlag, dynamicChildren, dirs } = n2
// ---- 属性更新 ----
if (patchFlag > 0) {
// 编译器告诉我们哪些属性是动态的
if (patchFlag & PatchFlags.FULL_PROPS) {
// 所有属性都可能变化，全量 diff
patchProps(el, n2, oldProps, newProps, parentComponent, parentSuspense, namespace)
} else {
// 按需更新
if (patchFlag & PatchFlags.CLASS) {
if (oldProps.class !== newProps.class) {
hostPatchProp(el, 'class', null, newProps.class, namespace)
}
}
if (patchFlag & PatchFlags.STYLE) {
hostPatchProp(el, 'style', oldProps.style, newProps.style, namespace)
}
if (patchFlag & PatchFlags.PROPS) {
// 只更新 dynamicProps 中列出的属性
const propsToUpdate = n2.dynamicProps!
for (let i = 0; i < propsToUpdate.length; i++) {
const key = propsToUpdate[i]
const prev = oldProps[key]
const next = newProps[key]
if (next !== prev || key === 'value') {
hostPatchProp(el, key, prev, next, namespace, parentComponent)
}
}
}
}
if (patchFlag & PatchFlags.TEXT) {
if (n1.children !== n2.children) {
hostSetElementText(el, n2.children as string)
}
}
} else if (!optimized && dynamicChildren == null) {
// 没有编译器优化标记，全量 diff 属性
patchProps(el, n2, oldProps, newProps, parentComponent, parentSuspense, namespace)
}
// ---- 子节点更新 ----
if (dynamicChildren) {
// Block 优化路径：只 patch 动态子节点
patchBlockChildren(n1.dynamicChildren!, dynamicChildren, el, parentComponent, parentSuspense, resolveChildrenNamespace(n2, namespace), slotScopeIds)
} else if (!optimized) {
// 全量子节点 diff
patchChildren(n1, n2, el, null, parentComponent, parentSuspense, resolveChildrenNamespace(n2, namespace), slotScopeIds, false)
}
}这段代码完美展示了 Vue 3 的编译-运行时协作：编译器通过 patchFlag 告诉运行时”哪些属性是动态的”，运行时就跳过所有静态属性的比较。这不是运行时的聪明，而是编译器的先见之明。
11.4 patchChildren：子节点 Diff 的入口
从这里开始进入全章的核心。子节点 Diff 是整个 VDOM 更新的”最难一块”——父节点的更新是简单的属性比对，但子节点是一个序列，序列的对比是 CS 经典难题之一。
Vue 3 对子节点 diff 的处理分两层：有 key 和无 key。
- 无 key：当作”两个同质的元素列表”，逐一位置对比。简单但低效，每个位置差异都意味着 DOM 操作。
- 有 key：当作”两组有身份标识的元素”，用双端扫描 + LIS 找出最少 DOM 移动。
这两条路径共用的一个前提是：旧 VNode 列表 × 新 VNode 列表 → 一组 DOM 操作。无论具体算法怎么变，输入输出的形状不变。这种用算法替换、接口稳定的设计让 Vue 可以在后续版本中无痛升级 diff 算法（例如 3.0 的双端、3.2 的 LIS 改进）——上层调用方不用改代码。
子节点的更新是 Diff 算法的核心战场。patchChildren 需要处理多种情况：
const patchChildren: PatchChildrenFn = (
n1, n2, container, anchor,
parentComponent, parentSuspense, namespace, slotScopeIds, optimized
) => {
const c1 = n1 && n1.children
const prevShapeFlag = n1 ? n1.shapeFlag : 0
const c2 = n2.children
const { patchFlag, shapeFlag } = n2
if (patchFlag > 0) {
if (patchFlag & PatchFlags.KEYED_FRAGMENT) {
// 所有子节点都有 key
patchKeyedChildren(c1 as VNode[], c2 as VNodeArrayChildren, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
return
} else if (patchFlag & PatchFlags.UNKEYED_FRAGMENT) {
// 所有子节点都没有 key
patchUnkeyedChildren(c1 as VNode[], c2 as VNodeArrayChildren, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
return
}
}
// 三种情况组合：新子节点是文本 / 数组 / 空
if (shapeFlag & ShapeFlags.TEXT_CHILDREN) {
if (prevShapeFlag & ShapeFlags.ARRAY_CHILDREN) {
unmountChildren(c1 as VNode[], parentComponent, parentSuspense)
}
if (c2 !== c1) {
hostSetElementText(container, c2 as string)
}
} else {
if (prevShapeFlag & ShapeFlags.ARRAY_CHILDREN) {
if (shapeFlag & ShapeFlags.ARRAY_CHILDREN) {
// 数组 → 数组：全量 Diff
patchKeyedChildren(c1 as VNode[], c2 as VNodeArrayChildren, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else {
// 数组 → 空：卸载所有
unmountChildren(c1 as VNode[], parentComponent, parentSuspense, true)
}
} else {
if (prevShapeFlag & ShapeFlags.TEXT_CHILDREN) {
hostSetElementText(container, '')
}
if (shapeFlag & ShapeFlags.ARRAY_CHILDREN) {
mountChildren(c2 as VNodeArrayChildren, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
}
}
}
}flowchart TD
A[patchChildren] --> B{patchFlag?}
B -->|KEYED_FRAGMENT| C[patchKeyedChildren]
B -->|UNKEYED_FRAGMENT| D[patchUnkeyedChildren]
B -->|其他| E{新子节点类型}
E -->|文本| F[设置文本内容]
E -->|数组| G{旧子节点类型}
E -->|空| H[卸载旧子节点]
G -->|数组| C
G -->|文本/空| I[挂载新子节点]
11.5 核心算法：patchKeyedChildren
这一节是全章最密、也最值得精读的内容——五步算法 + LIS 是 Vue diff 最精巧的工程实现。别被它的抽象迷惑，用具体例子走一遍就会豁然开朗。
理解这节的价值不只在于”看懂 Vue 怎么写的 diff”。更重要的是：这套思路在任何”两个序列找最小修改”的场景下都能直接迁移——从 git diff 的经典 Myers 算法，到 CRDT 里的 OT 同步，到 JSON Patch 的 add/remove/move 操作——都是同一类问题的不同约束下变体。把 Vue 的 diff 吃透，相当于给自己多装了一把通用锤子。
这是 Vue 3 Diff 算法的核心，也是面试中最常被问到的部分。算法分为五个步骤：
const patchKeyedChildren = (
c1: VNode[],
c2: VNodeArrayChildren,
container: RendererElement,
parentAnchor: RendererNode | null,
parentComponent: ComponentInternalInstance | null,
parentSuspense: SuspenseBoundary | null,
namespace: ElementNamespace,
slotScopeIds: string[] | null,
optimized: boolean
) => {
let i = 0
const l2 = c2.length
let e1 = c1.length - 1 // 旧数组尾指针
let e2 = l2 - 1 // 新数组尾指针
// ======== 第一步：从头部开始同步 ========
// (a b) c d
// (a b) e c d
while (i <= e1 && i <= e2) {
const n1 = c1[i]
const n2 = (c2[i] = optimized
? cloneIfMounted(c2[i] as VNode)
: normalizeVNode(c2[i]))
if (isSameVNodeType(n1, n2)) {
patch(n1, n2, container, null, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else {
break
}
i++
}
// ======== 第二步：从尾部开始同步 ========
// a (b c)
// a d e (b c)
while (i <= e1 && i <= e2) {
const n1 = c1[e1]
const n2 = (c2[e2] = optimized
? cloneIfMounted(c2[e2] as VNode)
: normalizeVNode(c2[e2]))
if (isSameVNodeType(n1, n2)) {
patch(n1, n2, container, null, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else {
break
}
e1--
e2--
}
// ======== 第三步：处理仅有新增的情况 ========
// (a b)
// (a b) c d
if (i > e1) {
if (i <= e2) {
const nextPos = e2 + 1
const anchor = nextPos < l2 ? (c2[nextPos] as VNode).el : parentAnchor
while (i <= e2) {
patch(null, (c2[i] = optimized ? cloneIfMounted(c2[i] as VNode) : normalizeVNode(c2[i])), container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
i++
}
}
}
// ======== 第四步：处理仅有删除的情况 ========
// (a b) c d
// (a b)
else if (i > e2) {
while (i <= e1) {
unmount(c1[i], parentComponent, parentSuspense, true)
i++
}
}
// ======== 第五步：处理中间乱序部分 ========
else {
const s1 = i // 旧序列中间段起点
const s2 = i // 新序列中间段起点
// 5.1 建立 key → index 映射
const keyToNewIndexMap: Map<PropertyKey, number> = new Map()
for (i = s2; i <= e2; i++) {
const nextChild = (c2[i] = optimized
? cloneIfMounted(c2[i] as VNode)
: normalizeVNode(c2[i]))
if (nextChild.key != null) {
keyToNewIndexMap.set(nextChild.key, i)
}
}
// 5.2 遍历旧序列，尝试 patch 或移除
let j
let patched = 0
const toBePatched = e2 - s2 + 1
let moved = false
let maxNewIndexSoFar = 0
const newIndexToOldIndexMap = new Array(toBePatched).fill(0)
for (i = s1; i <= e1; i++) {
const prevChild = c1[i]
if (patched >= toBePatched) {
// 新序列已全部处理完，剩余旧节点直接卸载
unmount(prevChild, parentComponent, parentSuspense, true)
continue
}
let newIndex
if (prevChild.key != null) {
newIndex = keyToNewIndexMap.get(prevChild.key)
} else {
// 无 key 节点：线性扫描查找
for (j = s2; j <= e2; j++) {
if (newIndexToOldIndexMap[j - s2] === 0 && isSameVNodeType(prevChild, c2[j] as VNode)) {
newIndex = j
break
}
}
}
if (newIndex === undefined) {
unmount(prevChild, parentComponent, parentSuspense, true)
} else {
newIndexToOldIndexMap[newIndex - s2] = i + 1
if (newIndex >= maxNewIndexSoFar) {
maxNewIndexSoFar = newIndex
} else {
moved = true
}
patch(prevChild, c2[newIndex] as VNode, container, null, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
patched++
}
}
// 5.3 移动和挂载
const increasingNewIndexSequence = moved
? getSequence(newIndexToOldIndexMap)
: EMPTY_ARR
j = increasingNewIndexSequence.length - 1
for (i = toBePatched - 1; i >= 0; i--) {
const nextIndex = s2 + i
const nextChild = c2[nextIndex] as VNode
const anchor = nextIndex + 1 < l2 ? (c2[nextIndex + 1] as VNode).el : parentAnchor
if (newIndexToOldIndexMap[i] === 0) {
// 新节点，挂载
patch(null, nextChild, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else if (moved) {
if (j < 0 || i !== increasingNewIndexSequence[j]) {
// 需要移动
move(nextChild, container, anchor, MoveType.REORDER)
} else {
j-- // 不需要移动
}
}
}
}
}五步算法详解
Vue 的 patchKeyedChildren 用了一种 pragmatic 的策略——不纯用 LIS 算法、而是先用几个快速路径处理常见场景，只把真正乱序的情况才丢给 LIS。
这是一种典型的工程 trick：LIS 理论复杂度好，但常数因子大（需要构造辅助数组、二分查找等）。真实工作负载下 90% 以上的更新是”前缀/后缀/纯新增/纯删除”之一——这四种用廉价的双指针就能处理完，根本不用启动 LIS 的大炮。
具体五步是：
- 头部同步（同步扫描新旧数组的头部，同 key 的就复用、原地 patch）
- 尾部同步（同步扫描尾部）
- 纯新增（旧的扫完了但新的还有剩，剩下的 mount）
- 纯删除（新的扫完了但旧的还有剩，剩下的 unmount）
- 乱序处理（新旧数组中间都有残余，走 LIS）
前两步是O(min(m,n)) 的线性扫描，第三第四步是O(diff) 的线性操作，只有第五步会触发 O(n log n) 的 LIS。实际测试，超过 80% 的列表更新在前两步就能完成；LIS 主要服务的是”排序/拖拽/数据重组”这类真正的乱序。
这种”先快速路径再通用算法”的做法在系统软件里极常见——Linux 内核的调度器、JS V8 引擎的对象属性访问、数据库的查询优化器，全都采用类似的”fast path + slow path”结构。掌握这种分层思维，能帮你看懂很多看似”复杂”的真实系统。
让我们用一个具体的例子来理解这五个步骤：
旧序列: a b [c d e f] g h
新序列: a b [e d c k] g h第一步：头部同步。从头扫描，a 和 b 类型和 key 都相同，直接 patch 更新。i 停在位置 2。
第二步：尾部同步。从尾扫描，h 和 g 类型和 key 都相同，直接 patch。e1 停在位置 5，e2 停在位置 5。
第三、四步：不满足纯新增或纯删除的条件，跳过。
第五步：处理中间的乱序部分 [c d e f] → [e d c k]：
graph LR
subgraph 旧序列
C1[c:2] --> D1[d:3] --> E1[e:4] --> F1[f:5]
end
subgraph 新序列
E2[e:2] --> D2[d:3] --> C2[c:4] --> K2[k:5]
end
C1 -.->|"key=c"| C2
D1 -.->|"key=d"| D2
E1 -.->|"key=e"| E2
F1 -.->|"无匹配→卸载"| X[❌]
K2 -.->|"新增→挂载"| Y[✅]
- 建立新序列的
keyToNewIndexMap：{e: 2, d: 3, c: 4, k: 5} - 遍历旧序列
[c, d, e, f]：c→ 新位置 4，newIndexToOldIndexMap[2] = 3d→ 新位置 3，newIndexToOldIndexMap[1] = 4e→ 新位置 2，newIndexToOldIndexMap[0] = 5，但 2 < maxNewIndexSoFar(4)，标记moved = truef→ 无匹配，卸载
- 计算最长递增子序列
[0, 1]（对应e, d，不需要移动） - 从后向前遍历，
k是新节点，挂载；c不在子序列中，需要移动
最长递增子序列（LIS）
这是整个 Diff 算法中最精妙的部分。getSequence 函数计算 newIndexToOldIndexMap 中的最长递增子序列，这些位置上的节点不需要移动——它们已经保持了相对顺序。
// packages/runtime-core/src/renderer.ts
function getSequence(arr: number[]): number[] {
const p = arr.slice() // 前驱数组，记录每个元素在 LIS 中的前一个位置
const result = [0] // 结果数组，存储 LIS 的索引
let i, j, u, v, c
const len = arr.length
for (i = 0; i < len; i++) {
const arrI = arr[i]
if (arrI !== 0) { // 0 表示新节点，跳过
j = result[result.length - 1]
if (arr[j] < arrI) {
// arrI 大于当前 LIS 尾部，直接追加
p[i] = j
result.push(i)
continue
}
// 二分查找：找到 result 中第一个 >= arrI 的位置
u = 0
v = result.length - 1
while (u < v) {
c = (u + v) >> 1
if (arr[result[c]] < arrI) {
u = c + 1
} else {
v = c
}
}
if (arrI < arr[result[u]]) {
if (u > 0) {
p[i] = result[u - 1]
}
result[u] = i
}
}
}
// 回溯前驱数组，重建完整的 LIS
u = result.length
v = result[u - 1]
while (u-- > 0) {
result[u] = v
v = p[v]
}
return result
}时间复杂度 O(n log n)，空间复杂度 O(n)。这个算法的价值在于：它将 DOM 移动操作降到最少。每一次 DOM 移动都是昂贵的——它触发回流、重绘。LIS 确保我们只移动必须移动的节点。
为什么是”最长递增子序列”
LIS 第一次出现在前端教程里常常让人困惑——“列表更新和递增子序列有什么关系？“这个 mapping 值得专门讲一下。
想象一下这个场景：旧列表是 [A, B, C, D, E]，新列表是 [E, A, B, C, D]——E 从末尾被移动到了开头。用什么方法知道”应该搬 E，而不是搬 A、B、C、D”？
把每个新位置上的元素在旧数组中的下标写出来：[4, 0, 1, 2, 3]（新位置 0 上是 E，E 在旧数组索引 4；新位置 1 上是 A，A 在旧数组索引 0；……）。这个下标数组里最长的递增子序列是 [0, 1, 2, 3]，对应元素 A、B、C、D——这四个元素可以保持相对顺序不动，只要把剩下的 E 插到合适位置即可。
这就是 LIS 算法在 Diff 里的角色：找出哪些元素可以保持原位、不动 DOM。LIS 外的元素才需要真正的 DOM move（或 insertBefore）。不用 LIS 的朴素做法是”逐个比对、不对就搬”——最坏情况下每个元素都被 move 一次，100 个元素就是 100 次 DOM 操作。用了 LIS，假设 LIS 长度 80，只需要 move 20 个——DOM 操作量砍掉 4/5。
Vue 的 LIS 实现是 O(n log n) 的典型算法（二分 + dp 数组），源码里注释标注得很清楚。这个算法 1935 年就被数学家 Erdős 和 Szekeres 证明，直到 2019 年被 Inferno.js 首先用在前端 Diff 里，Vue 3、Snabbdom 随后跟进。一个近 90 年前的算法、用在最新的前端框架里——这是 CS 经典算法”永不过时”的典型例证。
没有 key 会怎样？
const patchUnkeyedChildren = (
c1: VNode[], c2: VNodeArrayChildren,
container: RendererElement, anchor: RendererNode | null,
parentComponent: ComponentInternalInstance | null,
parentSuspense: SuspenseBoundary | null,
namespace: ElementNamespace, slotScopeIds: string[] | null,
optimized: boolean
) => {
c1 = c1 || EMPTY_ARR
c2 = c2 || EMPTY_ARR
const oldLength = c1.length
const newLength = c2.length
const commonLength = Math.min(oldLength, newLength)
let i
for (i = 0; i < commonLength; i++) {
const nextChild = (c2[i] = optimized
? cloneIfMounted(c2[i] as VNode)
: normalizeVNode(c2[i]))
patch(c1[i], nextChild, container, null, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
}
if (oldLength > newLength) {
unmountChildren(c1, parentComponent, parentSuspense, true, false, commonLength)
} else {
mountChildren(c2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized, commonLength)
}
}没有 key 的列表 Diff 极其简单——按索引逐一比较。这意味着如果你在列表头部插入一个元素，所有元素都会被”误认为”类型不匹配或者内容变化，导致大量不必要的 DOM 更新。这就是 Vue 官方文档反复强调 v-for 必须加 :key 的原因。
11.6 Block Tree 与 PatchFlag：编译时优化
Block Tree 是 Vue 3 相对 Vue 2 最大的性能进步。它的思路一句话总结：既然我编译期就知道哪些节点会动、哪些不会动，为什么还要让运行时每次都全量比对？
这个思路在传统的 VNode 系统里不成立——React 的 diff 纯粹是运行时行为，它不相信编译期能告诉它任何东西，因为 JSX 可以任意动态（你可以在 render 里条件生成任何子树）。Vue 的模板是受限的 DSL，指令（v-if、v-for、{{}} 绑定）是明确的、可以静态分析的——这让编译器有能力做”预判”。Vue 3 团队拿下这个机会，设计了 Block Tree。
这就是为什么 Vue 3 号称 diff 是 “fast enough that you don’t think about it”：编译期已经把”需要检查什么”压缩到最小，运行时只剩下真正必要的比对。一个典型 Vue 组件 render 里可能有几百个节点，但动态节点（Block 收集的）只有几个——diff 复杂度从 O(template size) 降到了 O(dynamic nodes)。
传统 Diff 的问题
Vue 2 时代的 diff 和 React 长期共享同一类做法：对新旧子节点做完整的一对一比较。这个做法简单可靠，但在 Vue 的模板上下文下它是过度保守的。
考虑一个最朴素的模板：
<template>
<div>
<h1>我的博客</h1>
<p class="subtitle">子标题</p>
<article>{{ content }}</article>
<footer>版权所有</footer>
</template>这里只有 {{ content }} 可能变，其他四个节点永远不变。但 Vue 2 的 diff 会把这五个节点每次全量比对一遍：h1 的 tagName、p 的 class、article 的子节点是否变化、footer 的文本——即使编译器已经看得出来前 4 个都是静态的。每次更新的 diff 工作量和”可能变化的数量”无关、和”节点总数”有关——这就是传统 diff 的本质浪费。
React 承受这个浪费是因为它的 JSX 动态性。Vue 的模板是静态可分析的——凭什么要承受这个浪费？
Block Tree 的答案是：“不用承受”。编译器在生成 render 函数时，把所有”可能变化的节点”登记在一个 Block 数组里；运行时 diff 只遍历这个数组，跳过所有静态节点。上面的模板生成的 render 函数里，Block 数组长度是 1（只有 article 可能变）——diff 的工作量从 5 降到 1。一个大型表格组件里这个比例可能是 “1000 节点只有 10 个可能变”——运行时 diff 成本几乎被编译期吸收掉了。
考虑一个模板：
<div>
<h1>静态标题</h1>
<p>这是一段静态文本</p>
<span>另一段静态文本</span>
<p>{{ dynamicText }}</p>在传统的 Diff 中（如 React），即使只有最后一个 <p> 是动态的，算法也需要遍历所有四个子节点。当组件很大、静态内容很多时，这种遍历是浪费的。
Block 的概念
Vue 3 引入了 Block Tree 来解决这个问题。编译器会将模板中的动态节点”提升”到一个 Block 中：
// 编译器输出（简化）
function render(_ctx) {
return (_openBlock(), _createElementBlock("div", null, [
_createElementVNode("h1", null, "静态标题"),
_createElementVNode("p", null, "这是一段静态文本"),
_createElementVNode("span", null, "另一段静态文本"),
_createElementVNode("p", null, _toDisplayString(_ctx.dynamicText), 1 /* TEXT */)
]))
}_openBlock() 打开一个 Block 上下文，_createElementBlock() 创建 Block 根节点。在这个过程中，带有 patchFlag（这里是 1 = TEXT）的 VNode 会被收集到 Block 的 dynamicChildren 数组中。
// packages/runtime-core/src/vnode.ts
export function openBlock(disableTracking = false) {
blockStack.push((currentBlock = disableTracking ? null : []))
}
export function createElementBlock(
type: string | typeof Fragment,
props?: Record<string, any> | null,
children?: any,
patchFlag?: number,
dynamicProps?: string[],
shapeFlag?: number
) {
return setupBlock(
createBaseVNode(type, props, children, patchFlag, dynamicProps, shapeFlag, true)
)
}
function setupBlock(vnode: VNode) {
vnode.dynamicChildren =
isBlockTreeEnabled > 0 ? currentBlock || (EMPTY_ARR as any) : null
closeBlock()
if (isBlockTreeEnabled > 0 && currentBlock) {
currentBlock.push(vnode)
}
return vnode
}patchBlockChildren：跳过静态节点
Block Tree 的效果在这个函数里落地。和 patchKeyedChildren 的最大区别是——它完全不做子节点的身份判定、不考虑乱序。它假定”dynamicChildren 数组里的 VNode 按位置一一对应旧的 dynamicChildren”，直接对每个位置上的 VNode 走 patch。
这个”敢不做身份判定”的底气来自编译器保证：dynamicChildren 的长度和顺序在同一个 Block 内部是稳定的——因为每个 dynamic VNode 对应模板里的一个固定位置。v-if / v-for 会破坏这个稳定性（新增或删除节点），所以它们要开新 Block。这就是为什么 Block Tree 不是”全局一个 Block”而是”嵌套的 Block 森林”。
当 Block 存在 dynamicChildren 时，更新只需要遍历动态子节点：
const patchBlockChildren: PatchBlockChildrenFn = (
oldChildren, newChildren, fallbackContainer,
parentComponent, parentSuspense, namespace, slotScopeIds
) => {
for (let i = 0; i < newChildren.length; i++) {
const oldVNode = oldChildren[i]
const newVNode = newChildren[i]
const container =
oldVNode.el &&
(oldVNode.type === Fragment ||
!isSameVNodeType(oldVNode, newVNode) ||
oldVNode.shapeFlag & (ShapeFlags.COMPONENT | ShapeFlags.TELEPORT))
? hostParentNode(oldVNode.el!)!
: fallbackContainer
patch(oldVNode, newVNode, container, null, parentComponent, parentSuspense, namespace, slotScopeIds, true)
}
}在上面的例子中，dynamicChildren 只有一个元素（那个绑定了 dynamicText 的 <p>），所以更新只需要一次 patch 调用。三个静态节点完全被跳过。
PatchFlag 枚举
PatchFlag 是编译器塞给每个 dynamic VNode 的”这个节点的哪些方面可能变”的标记。有了这个标记，patch 函数连属性比较都能省掉——直接按 flag 指示去更新对应的部分。
具体哪些 flag、每个对应什么优化路径，下面分条列出。看的时候想一个问题：这些 flag 的集合大小（不到 20 个）暗示了什么？——暗示了 Vue 模板的动态性边界是可枚举的有限集合，这正是 Vue 能做模板级静态优化的前提。JSX 无法做到同样的事，因为 JSX 的动态性是无界的（你可以在 render 里做任何事）。
// packages/shared/src/patchFlags.ts
export enum PatchFlags {
TEXT = 1, // 动态文本内容
CLASS = 1 << 1, // 动态 class
STYLE = 1 << 2, // 动态 style
PROPS = 1 << 3, // 动态属性（不含 class、style）
FULL_PROPS = 1 << 4, // 有动态 key 的属性，需要全量 diff
NEED_HYDRATION = 1 << 5, // 需要事件监听器的 hydration
STABLE_FRAGMENT = 1 << 6, // 子节点顺序不变的 Fragment
KEYED_FRAGMENT = 1 << 7, // 子节点有 key 的 Fragment
UNKEYED_FRAGMENT = 1 << 8,// 子节点无 key 的 Fragment
NEED_PATCH = 1 << 9, // 只需要非属性 patch（ref、指令）
DYNAMIC_SLOTS = 1 << 10, // 动态插槽
DEV_ROOT_FRAGMENT = 1 << 11,
// ---- 特殊标记（负值，不会被 > 0 检查命中）----
HOISTED = -1, // 静态提升的节点
BAIL = -2 // 放弃优化（例如非编译器生成的渲染函数）
}每个 PatchFlag 都精确地告诉运行时”这个节点的哪个部分是动态的”。运行时根据这些标记做最小化更新——这就是 Vue 3 比 React 在更新性能上更优的关键原因之一。
11.7 静态提升（Static Hoisting）
如果说 Block Tree 解决的是”运行时不用 diff 静态节点”，静态提升解决的是更前置的一件事：根本不用每次创建静态 VNode 对象。
编译器还有一个更激进的优化：将完全静态的 VNode 提升到渲染函数之外：
// 编译器输出（启用 hoistStatic）
const _hoisted_1 = _createElementVNode("h1", null, "静态标题")
const _hoisted_2 = _createElementVNode("p", null, "这是一段静态文本")
const _hoisted_3 = _createElementVNode("span", null, "另一段静态文本")
function render(_ctx) {
return (_openBlock(), _createElementBlock("div", null, [
_hoisted_1,
_hoisted_2,
_hoisted_3,
_createElementVNode("p", null, _toDisplayString(_ctx.dynamicText), 1 /* TEXT */)
]))
}提升的 VNode 只创建一次，每次渲染都复用同一个对象。它们的 patchFlag 被标记为 HOISTED = -1，运行时看到这个标记就知道可以完全跳过。
更进一步，当连续的静态节点超过一定数量时，编译器会将它们合并为一个静态字符串：
const _hoisted_1 = _createStaticVNode(
'<h1>静态标题</h1><p>这是一段静态文本</p><span>另一段静态文本</span>',
3 // 节点数量
)这种 stringification 直接用 innerHTML 插入，彻底跳过了 VNode 创建和 Diff 的开销。
11.8 Fragment、Teleport 与 Suspense
这三种”特殊 VNode”从语义上看差别很大——Fragment 是”一组没有根的节点”，Teleport 是”想挂到别处的节点”，Suspense 是”等异步解析的节点”。但从 VDOM 的角度它们共享一个本质：跳出常规的”VNode 对应一个 DOM 节点”对应关系。
这一节看源码的价值，不仅在于学会这三个组件怎么用，更在于看 Vue 团队如何在已有 VDOM 抽象上增加”不规则”的节点类型，而不破坏核心 diff 逻辑。每一种都是在 patch 函数里加一个独立分支，由 ShapeFlag 识别、由各自的 process 函数处理。这种按”类型”分发而不是在 diff 主逻辑里埋 if 分支的设计，让 Vue 可以持续增加特殊节点（未来可能的 Lazy Component、Portal 变种、Island Hydration 节点）而不动核心代码。
Fragment：无根节点渲染
Fragment 是 Vue 3 相对 Vue 2 最”小但重要”的改进。Vue 2 要求组件必须有单一根节点——不能写 <template><div/><div/></template>——很多真实场景被迫套一层 <div> 纯包裹，这就是”div 之祸”：DOM 深度无意义地增加、CSS 布局（Flex/Grid）被破坏、Accessibility 树的语义干扰。
Vue 3 允许组件模板有多个根节点，这通过 Fragment 实现：
const processFragment = (
n1: VNode | null,
n2: VNode,
container: RendererElement,
anchor: RendererNode | null,
parentComponent: ComponentInternalInstance | null,
parentSuspense: SuspenseBoundary | null,
namespace: ElementNamespace,
slotScopeIds: string[] | null,
optimized: boolean
) => {
const fragmentStartAnchor = (n2.el = n1 ? n1.el : hostCreateText(''))!
const fragmentEndAnchor = (n2.anchor = n1 ? n1.anchor : hostCreateText(''))!
let { patchFlag, dynamicChildren } = n2
if (n1 == null) {
// 挂载：插入两个空文本节点作为锚点
hostInsert(fragmentStartAnchor, container, anchor)
hostInsert(fragmentEndAnchor, container, anchor)
// 在两个锚点之间挂载子节点
mountChildren(n2.children as VNodeArrayChildren, container, fragmentEndAnchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
} else {
// 更新
if (patchFlag > 0 && patchFlag & PatchFlags.STABLE_FRAGMENT && dynamicChildren && n1.dynamicChildren) {
patchBlockChildren(n1.dynamicChildren, dynamicChildren, container, parentComponent, parentSuspense, namespace, slotScopeIds)
} else {
patchChildren(n1, n2, container, fragmentEndAnchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
}
}
}Fragment 使用两个空文本节点作为边界标记（anchor），子节点就插入在这两个锚点之间。这是一个巧妙的设计——它不需要额外的 DOM 容器，只需要两个几乎零开销的文本节点。
Teleport：跨越 DOM 边界
Teleport 解决的痛点是”组件定义位置 vs DOM 挂载位置”的分离。最典型的场景是 Modal / Toast——业务上它们写在某个组件里（逻辑上属于那个组件），但物理上必须挂到 body 上（避免被父组件的 overflow、z-index、transform 裁剪）。
Teleport 让子节点渲染到 DOM 树的另一个位置：
// packages/runtime-core/src/components/Teleport.ts（简化）
const TeleportImpl = {
process(n1, n2, container, anchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized, internals) {
const { mc: mountChildren, pc: patchChildren, pbc: patchBlockChildren, o: { insert, querySelector, createText } } = internals
const target = (n2.target = resolveTarget(n2.props, querySelector))
if (n1 == null) {
// 挂载
const targetAnchor = (n2.targetAnchor = createText(''))
if (target) {
insert(targetAnchor, target)
mountChildren(n2.children, target, targetAnchor, parentComponent, parentSuspense, namespace, slotScopeIds, optimized)
}
} else {
// 更新
n2.el = n1.el
const mainAnchor = (n2.anchor = n1.anchor)!
const targetAnchor = (n2.targetAnchor = n1.targetAnchor)!
if (n2.dynamicChildren) {
patchBlockChildren(n1.dynamicChildren!, n2.dynamicChildren, target!, parentComponent, parentSuspense, namespace, slotScopeIds)
} else if (!optimized) {
patchChildren(n1, n2, target!, targetAnchor, parentComponent, parentSuspense, namespace, slotScopeIds, false)
}
// 如果 target 变了，需要迁移子节点
if (target !== n1.target) {
moveTeleport(n2, target, null, internals, TeleportMoveTypes.TARGET_CHANGE)
}
}
}
}Teleport 的 Diff 和普通元素类似，关键区别在于子节点的容器是 target 而非父节点的容器。当 to 属性变化时，还需要执行一次完整的节点迁移。
11.9 Diff 算法的复杂度分析
理论分析很重要，但要和实际工作负载对齐——否则就是纸上谈兵。
让我们整理一下各种情况的时间复杂度：
| 场景 | 时间复杂度 | 说明 |
|---|---|---|
| 头尾同步 | O(min(m,n)) | 前两步的线性扫描 |
| 纯新增/纯删除 | O(|差异|) | 只处理差异部分 |
| 乱序 Diff（无 key） | O(m × n) | 每个旧节点线性扫描新序列 |
| 乱序 Diff（有 key） | O(n + m) 建图 + O(n log n) LIS | 哈希映射 + 二分查找 |
| Block 优化 | O(动态节点数) | 跳过所有静态节点 |
其中 m 和 n 分别是旧、新子节点数组的长度。
关键洞察：Vue 3 的 Diff 不是一个统一算法，而是一组分层优化策略的组合。大部分实际场景都会被前两步的头尾同步处理掉（列表末尾追加/删除），只有少数复杂的列表重排才会走到 LIS 算法。
11.10 与其他框架的对比
三大前端框架的 diff 思路完全不同，选取哪种路线和各自的目标用户群深度绑定。不理解这一点，容易把比较变成”谁性能高”的无聊竞赛，忽略背后的设计哲学。
React 的 Fiber Diff
React 选了纯运行时、纯动态的路径。它相信 JSX 的灵活性是核心价值——开发者应该能在 render 里随意用 JavaScript 表达 UI，不受模板语法限制。这个立场有一个代价：编译器对 UI 结构一无所知，运行时必须把每一个子树当作”可能完全变了”来处理。丛书卷《React 19 源码解读》第 6-9 章详细讲了 Fiber 如何通过”可中断的遍历 + 双缓冲树”弥补这点。
React 使用单向链表结构（Fiber）而非数组来表示子节点。Diff 只做一次从左到右的扫描，没有尾部同步。对于”在列表头部插入”这类操作，React 的 Diff 效率低于 Vue 3，因为它无法利用尾部的稳定节点。
React 也没有编译时优化——它不知道哪些属性是动态的，每次都需要全量比较 props。
Svelte 的编译时方法
Svelte 走了全编译时的极端——完全不需要 VDOM。模板被编译成直接操作 DOM 的命令式代码，每个组件的 render 其实是”已经展开好的 DOM 操作序列”。这种做法极致省运行时：生成代码里没有 VDOM 数据结构、没有 diff 算法、没有调度器。代价是开发时的灵活性：Svelte 的模板表达力受限（不能随意用 JS 生成节点、没有类似 React 的渲染 prop 模式）；以及bundle size 在节点数量多时反而会超过 VDOM 方案（因为每个节点都要编译出专属操作代码）。
Vue 3 的 Block Tree 是在两个极端之间找到的平衡点：能静态分析的部分由编译器优化、不能静态分析的部分回退到 VDOM 动态 diff。这是 Vue 一贯的”渐进式”哲学——不强行让开发者站在任何一边。而 Vue 3.6 引入的 Vapor Mode 则是往 Svelte 方向更进一步的实验：为特定组件生成命令式 DOM 操作代码，绕过 VDOM。这是 Vue 对”未来渲染模型是什么”的对答——VDOM 依然会在，但对性能极敏感的场景可以选 Vapor。
Svelte 走向了另一个极端：完全在编译时分析出所有可能的变化路径，生成直接操作 DOM 的命令式代码。没有虚拟 DOM，没有 Diff，更新是 O(1) 的。
Vue 3.6 的 Vapor Mode（我们在第 9 章讨论过）借鉴了这个思路，但走了一条中间路线——在 Vapor Mode 下，简单组件编译为直接 DOM 操作，复杂组件仍然使用 VNode。
对比总结
graph LR
subgraph 编译时信息量
direction TB
Svelte[Svelte: 完全编译时]
Vue[Vue 3: 编译时 + 运行时协作]
React[React: 纯运行时]
end
subgraph 更新策略
direction TB
S[Svelte: 直接 DOM 操作]
V[Vue 3: Block Tree + Diff]
R[React: Fiber Diff]
end
Svelte --> S
Vue --> V
React --> R
11.11 实战调试：观察 Diff 过程
前面讲的所有机制都可以亲手验证。只要学会用 Vue DevTools 的 Timeline 面板 + Chrome Performance 面板结合，你能清楚看到每次组件更新触发了哪些 VNode 创建、哪些被 patch、哪些因 Block Tree 被跳过。以下是一个我在生产里用来排查”为什么这个大列表更新卡”的流程，推荐收藏。
在开发模式下，你可以通过 __vue_app__ 访问应用实例，观察 VNode 树的结构：
// 在浏览器控制台
const app = document.querySelector('#app').__vue_app__
const rootComponent = app._instance
const subTree = rootComponent.subTree
// 查看 VNode 类型
console.log(subTree.type) // 'div' 或 Fragment
console.log(subTree.shapeFlag) // 17 = ELEMENT | ARRAY_CHILDREN
console.log(subTree.patchFlag) // 编译器标记
// 查看动态子节点
console.log(subTree.dynamicChildren) // Block 收集的动态节点
// 递归打印 VNode 树
function printVNode(vnode: any, depth = 0) {
const indent = ' '.repeat(depth)
const type = typeof vnode.type === 'string' ? vnode.type : vnode.type?.name || 'Fragment'
const flags = `shape=${vnode.shapeFlag} patch=${vnode.patchFlag}`
console.log(`${indent}<${type}> ${flags}`)
if (Array.isArray(vnode.children)) {
vnode.children.forEach((child: any) => {
if (child && child.__v_isVNode) {
printVNode(child, depth + 1)
}
})
}
}
printVNode(subTree)11.12 本章小结
关键要点：
-
VNode 是 UI 的中间表示，通过
shapeFlag编码类型信息，通过patchFlag携带编译时优化信息。 -
patch 函数是万物入口，根据 VNode 类型分发到不同的处理路径。
isSameVNodeType用type + key判断节点身份。 -
patchKeyedChildren 采用五步算法：头部同步 → 尾部同步 → 纯新增 → 纯删除 → 乱序处理（LIS）。大部分实际场景在前两步就能解决。
-
Block Tree 将更新范围从”所有子节点”缩小到”动态子节点”。编译器通过
openBlock/createElementBlock收集动态 VNode，运行时通过patchBlockChildren跳过静态内容。 -
静态提升和 stringification 进一步减少了 VNode 创建和内存分配的开销。
-
key 是 Diff 的灵魂——没有 key，列表更新退化为 O(m×n) 的逐一比较；有了 key，变成 O(n log n) 的 LIS 优化。
延伸阅读
从本章出发可以串联丛书里几条相关主线：
- 丛书卷《Vue 3 设计与实现》第 5 章讲 reactive 系统的依赖收集。Diff 触发是因为响应式数据变了 → effect 重新跑 → render 返回新 VNode → diff 拿到新旧两棵树。理解响应式触发 diff 的完整链路，才能看懂”为什么某个修改导致了这次更新”。
- 丛书卷《React 19 源码解读》第 6-9 章讲 Fiber 的实现。React 和 Vue 选了两条路，但遇到的问题是同一类——对比阅读能看清设计空间的边界。
- 丛书卷《Rust 编译器与运行时揭秘》第 5 章 讲 rustc 的 IR 和优化。Vue 编译器把模板编译成 render 函数 + patchFlag 的过程，和 rustc 把源码编译成 MIR 再做优化，是同构问题的不同实例——编译期能静态分析出的信息越多，运行时就能越”懒”。
- 丛书卷《Vite 设计与实现》第 11 章讲 SFC 编译。Vue 的模板 → render 函数这步，在 Vite 的 plugin 里完成；理解 Vite 如何调度 vue-plugin 的编译阶段，能让你看到本章讲的”编译期优化”到底在什么时候、什么进程里发生。
对读代码的建议
Vue 3 的 runtime-core 和 compiler-core 是两个独立 package：
packages/
runtime-core/src/
renderer.ts # patch / patchElement / patchChildren / patchKeyedChildren
vnode.ts # VNode 接口与 createVNode / cloneVNode / mergeProps
shared/src/
shapeFlags.ts # ShapeFlags 位掩码
patchFlags.ts # PatchFlags 枚举
compiler-core/src/
transforms/ # 编译期 transform（含 Block Tree 收集）
codegen.ts # 生成 render 函数字符串从 renderer.ts 的 patch 函数顺着看下去，一直读到 patchKeyedChildren，是最有”读源码获得感”的一条路径——每段代码都对应你熟悉的模板语法行为。读到 LIS 算法实现那段（getSequence 函数）可以专门停下来手工走一遍小例子，它是整份 runtime-core 里智力密度最高的 80 行。
至此 Vue 3 的核心渲染链路（响应式 → render → VNode → diff → DOM）全部打通。下一章（第 12 章）讲组件的生命周期与调度器——那一块是 Vue 如何把多次响应式触发合并成一次 render + 一次 diff 的调度机制，是整个运行时的指挥中枢。
思考题
-
为什么 Vue 3 的 Diff 算法从前后两端同时开始扫描，而不像 React 那样只从前向后扫描？这种设计在哪些场景下有明显优势？
-
patchFlag使用负数（-1、-2）来标记特殊状态（HOISTED、BAIL），为什么这些不能用正数的位掩码来表示？ -
如果你在
v-for中使用数组索引作为 key（:key="index"），在列表头部插入元素时会发生什么？画出 Diff 的过程并分析。 -
Block Tree 优化在什么情况下会失效（即
dynamicChildren为 null）？为什么v-if/v-for需要创建新的 Block？ -
最长递增子序列算法的 O(n log n) 复杂度是否足够好？有没有可能在特定场景下用更简单的方法达到相同效果？