Appearance
第 9 章 Vapor Mode：无虚拟 DOM 的编译目标
本章要点
- Vapor Mode 的设计动机：为什么 Vue 团队要在虚拟 DOM 之外开辟第二条渲染路径
- 编译策略的根本转变：从"生成 VNode 创建代码"到"生成 DOM 操作指令"
- Vapor 编译器的完整流水线：IR 生成、指令选择、代码输出
- 运行时的极简设计：无 VNode、无 Diff、无 Scheduler 的轻量执行模型
- 响应式驱动的精准更新：Effect 如何直接绑定到 DOM 操作
- 与传统 VDOM 模式的互操作：同一应用中两种模式的共存机制
- 性能对比：Bundle Size、首屏渲染、更新效率的实测数据分析
- Vapor Mode 对 Vue 生态和未来架构演进的深远影响
前八章中，我们深入剖析了 Vue 3 的响应式系统与编译器。你已经知道，Vue 3 通过 PatchFlags、Block Tree、静态提升等编译期优化，将运行时 Diff 的开销压缩到了极致。但无论怎么优化，只要渲染路径上仍然存在"创建 VNode → Diff VNode → Patch DOM"这条链路，就始终有一层抽象的开销无法消除。
2023 年底，尤雨溪在 VueConf 上首次公开了 Vapor Mode 的设计。这个名字暗示了它的本质——像水蒸气一样，虚拟 DOM 这层"水"被蒸发掉了，只留下最本质的东西：响应式状态到 DOM 操作的直接映射。
本章将完整拆解 Vapor Mode 的编译器与运行时。如果说前几章是在研究 Vue 的"经典力学"，那本章就是它的"量子跃迁"——同样的模板语法，全新的执行模型。
9.1 为什么需要 Vapor Mode
虚拟 DOM 的"不可压缩开销"
让我们先量化传统 VDOM 模式下一次更新的成本：
typescript
// 传统 VDOM 模式下，一个简单的计数器组件
const Counter = {
setup() {
const count = ref(0)
return () => h('div', [
h('span', { class: 'label' }, 'Count: '),
h('span', { class: 'value' }, count.value),
h('button', { onClick: () => count.value++ }, '+1')
])
}
}当 count 从 0 变为 1 时，更新链路是这样的：
count 变化
→ 触发组件的 renderEffect
→ 执行 render 函数，创建新的 VNode 树
→ h('div', ...) 创建 div VNode
→ h('span', ...) 创建两个 span VNode
→ h('button', ...) 创建 button VNode
→ patch(oldVNode, newVNode)
→ patchElement(div)
→ patchChildren(oldChildren, newChildren)
→ patch(oldSpan1, newSpan1) // 静态节点，跳过
→ patch(oldSpan2, newSpan2) // 文本变化
→ hostSetElementText(el, '1')
→ patch(oldButton, newButton) // 无变化，跳过即使有 PatchFlags 优化，我们仍然需要：
- 创建完整的 VNode 树（即使大部分节点没有变化）
- 逐层比对（即使 Block Tree 已经扁平化了 dynamic children）
- 维护 VNode 对象的生命周期（创建、引用、GC）
这三项开销，在 VDOM 架构下是结构性的——你无法通过更聪明的 Diff 算法来消除它们。正如 Svelte 的 Rich Harris 所言："最快的代码是不存在的代码。"
从 Svelte 和 Solid 获得的启示
在 Vue 之前，Svelte 和 Solid.js 已经证明了"无 VDOM"路线的可行性：
| 框架 | 策略 | 更新粒度 |
|---|---|---|
| Svelte | 编译期生成命令式 DOM 操作 | 语句级 |
| Solid.js | 编译期 + fine-grained reactivity | 表达式级 |
| Vue Vapor | 编译期 + alien signals | 表达式级 |
Vue Vapor Mode 的独特之处在于：它不是一个新框架，而是同一框架的第二种编译目标。你的 .vue 文件不需要任何修改，编译器会根据配置选择输出 VDOM 代码还是 Vapor 代码。这意味着：
- 你可以在同一个应用中混用两种模式
- 生态系统中的 Composition API 代码完全兼容
- 迁移成本几乎为零
Vapor Mode 的设计目标
尤雨溪在 RFC 中明确了三个核心目标：
- 更小的 Bundle：不需要 VDOM runtime（
renderer.ts、vnode.ts、diff相关代码约 15KB gzip），Vapor runtime 仅约 3KB gzip - 更快的更新：跳过 VNode 创建和 Diff，直接从响应式变化映射到 DOM 操作
- 更低的内存：不创建 VNode 对象，不维护新旧两棵树
9.2 Vapor 编译器架构
编译流水线对比
传统模式和 Vapor 模式共享相同的 Parse 阶段，但在 Transform 和 Codegen 阶段完全不同：
传统模式：
Template → Parse → AST → Transform → AST(with codegenNode) → Codegen → render()
↓
h() / createVNode()
Vapor 模式：
Template → Parse → AST → IR Transform → VaporIR → Codegen → setup()
↓
DOM 操作指令Vapor IR：中间表示
Vapor 编译器引入了一个全新的中间表示（Intermediate Representation），这是传统编译器中不存在的层级。Vapor IR 不是 AST 的简单变换，而是一种面向 DOM 操作的指令序列：
typescript
// packages/compiler-vapor/src/ir/index.ts
export interface RootIRNode {
type: IRNodeTypes.ROOT
source: string
template: string[] // 静态模板片段
block: BlockIRNode // 根 block
component: Set<string> // 使用到的组件
directive: Set<string> // 使用到的指令
effect: IREffect[] // 副作用列表
}
export interface BlockIRNode {
type: IRNodeTypes.BLOCK
dynamic: IRDynamicInfo // 动态节点信息
effect: IREffect[] // 此 block 的副作用
operation: OperationNode[] // 操作指令序列
returns: number[] // 返回的节点索引
}
// 操作指令类型
export const enum IRNodeTypes {
ROOT,
BLOCK,
// 创建操作
SET_TEXT, // 设置文本内容
SET_HTML, // 设置 innerHTML
SET_PROP, // 设置属性
SET_DYNAMIC_EVENTS, // 设置动态事件
SET_CLASS, // 设置 class
SET_STYLE, // 设置 style
SET_MODEL_VALUE, // 设置 v-model 值
// 结构操作
INSERT_NODE, // 插入节点
CREATE_TEXT_NODE, // 创建文本节点
CREATE_COMPONENT_NODE, // 创建组件节点
// 控制流
IF, // v-if
FOR, // v-for
SLOT_OUTLET, // slot 出口
}