阶段三从 React 的 Fiber 与并发一路走到今天，镜头该转向 Vue3 了。Vue3 和 React 站在性能问题的两端：React 没有编译期模板信息，所以用运行时调度换"可中断"；Vue3 手里握着模板编译器，用它换"更少的工作量"。今天把 Vue3 这套"响应式运行时 + 编译期静态分析"的合谋机制彻底拆开，回答一个问题：为什么一个 1000 行的列表更新，Vue3 可以只碰那几行变化的文本？
1. 技术难点
1.1 难点一：Vue2 的响应式天生粗糙
Vue2 用 Object.defineProperty 拦截属性读写，有几个结构性问题：
- 新增属性侦测不到 。
defineProperty只能拦截已存在的 key，运行时往对象上挂新属性（this.xxx = 1）没有 getter/setter，必须靠Vue.set补救。 - 数组是半残的 。索引赋值、
length修改侦测不全，只能 hackpush/pop/splice等七个方法。 - 初始化成本随对象体积线性涨 。
defineProperty必须在初始化时递归 walk 每一层、预埋每个 key 的 getter/setter，深层大对象首次响应化就是一次完整遍历。 - 更新粒度是组件级。一个组件里任何一个响应式数据变化，整个组件的 render 重跑、整棵 vdom 新旧对比，静态部分也跟着被反复 diff。
1.2 难点二：就算依赖收集精确了，diff 还是瓶颈
把响应式换成 Proxy 后，"哪个数据变了"能精确到 key 级。但注意：依赖收集只解决"谁订阅了这个数据"，没解决"这个数据的变化该落到 DOM 的哪个位置"。组件 effect 重跑时，render 生成的是整棵新 vnode 树，运行时 diff 默认要拿新旧两棵树逐节点对比，成本 O(整棵树规模)。而真实模板里往往七八成是永远不变的静态内容：固定文案、不变的 class、不参与渲染的结构标签。每次数据更新都重新对比这些节点，是纯粹的浪费。
1.3 难点三：想只对比动态节点，必须先回答"哪几个是动态的"
直觉解法是把动态节点单独收集成一个数组，更新时只按索引对比这个数组。但这套方案有一个致命前提：结构必须稳定 。平铺数组按索引一一对应，一旦出现 v-if（节点被整体删掉）或 v-for（列表项增删），索引整体错位：删掉第 2 项，后面所有动态节点的索引都左移一位，按索引对比就全对不上了。
"哪些节点是动态的"这个问题，运行时回答不了。vnode 是在运行时才被 h() 逐个创建出来的，跑起来的那一刻你无法区分它是模板里的固定文案还是 {{ msg }}。答案只存在于一个地方：模板源码。只有拿着模板做静态分析的编译器，才能在生成代码之前就知道哪个节点绑了数据、哪个节点是死的。所以 Vue3 的答案是：把模板交给编译器，让编译器在产物里把这些信息"盖章"出来。
2. 完整解法
Vue3 的性能架构是两条腿：运行时响应式做精（依赖收集到 key），编译器做准（把 diff 范围压到动态节点）。两条线在一个地方汇合：组件的 render effect。
2.1 第一半：Proxy + WeakMap，把依赖收集做到 key 级
运行时用 Proxy 全面接管对象读写，数据结构是三层：
vbnet
targetMap: WeakMap<目标对象, depsMap>
depsMap: Map<属性名, dep>
dep: Set<effect 订阅者>读取属性时 track 把当前正在运行的 effect 塞进对应 key 的 dep；写入属性时 trigger 把 dep 里的 effect 全部唤醒。Reflect.get/set 不是可选项：它保证拦截器拿到的 this 和访问器语义与原生读写一致，否则嵌套 getter 会漏收集或重复收集。
渲染侧，每个组件有一个"渲染 effect"：setup 里取到的 render（模板编译产物）被包进 effect，首次执行收集依赖。render 每读一个 _ctx.xxx，就完成一次 track；此后任何相关数据变化，trigger 把组件更新任务丢进调度队列，同一轮事件里的多次赋值会合并成一次渲染 （异步 flush，就是 nextTick 的底层）。
下面这段代码把整个运行时压缩成可运行的骨架（Node 直接跑），并演示"渲染 effect + 异步批量调度"：
js
// ===== 运行时第一半：track / trigger / reactive / effect =====
const targetMap = new WeakMap() // target -> depsMap
let activeEffect = null // 当前正在执行的 effect
function track(target, key) {
if (!activeEffect) return
let depsMap = targetMap.get(target)
if (!depsMap) targetMap.set(target, (depsMap = new Map()))
let dep = depsMap.get(key)
if (!dep) depsMap.set(key, (dep = new Set()))
dep.add(activeEffect) // 把当前 effect 订阅到该 key
}
function trigger(target, key) {
const dep = targetMap.get(target)?.get(key)
if (dep) dep.forEach(active =>
active.scheduler ? active.scheduler(active) : active())
// 有 scheduler 就走调度（入队异步批量执行），否则同步执行
}
function reactive(target) {
return new Proxy(target, {
get(t, k, receiver) {
track(t, k)
return Reflect.get(t, k, receiver) // this 与访问器语义保持一致
},
set(t, k, v, receiver) {
const result = Reflect.set(t, k, v, receiver)
trigger(t, k)
return result
},
})
}
// ===== 调度器：同一轮变更合并成一次 flush =====
const queue = new Set()
let isFlushing = false
function queueJob(job) {
queue.add(job)
if (isFlushing) return
isFlushing = true
Promise.resolve().then(() => {
isFlushing = false
const jobs = [...queue]
queue.clear()
jobs.forEach(j => j()) // 等价 Vue 的 flushJobs
})
}
// ===== effect：把 fn 变成订阅者，首次执行即收集依赖 =====
function effect(fn) {
const job = () => {
activeEffect = job
try { fn() } finally { activeEffect = null }
}
job.scheduler = queueJob
job()
return job
}
// ===== 使用：模拟一次组件渲染 =====
const state = reactive({ msg: 'hello' })
const titleNode = { textContent: '固定标题' } // 静态节点：创建一次，永不更新
const textNode = { textContent: '' } // 动态文本节点（对应 patchFlag = 1）
let renderCount = 0
effect(() => {
renderCount++
// 编译产物把 {{ msg }} 生成为 _toDisplayString(_ctx.msg)，
// 这次读取同时完成两件事：写文本 + 把本 effect 订阅到 state.msg
textNode.textContent = String(state.msg)
})
console.log(textNode.textContent) // hello
state.msg = 'world'
console.log(textNode.textContent) // 仍为 hello：更新进队列，还没 flush
Promise.resolve().then(() => {
console.log(textNode.textContent) // world：微任务里批量更新完成
console.log('renderCount:', renderCount) // 2；titleNode 全程未被触碰
})运行输出依次是 hello、hello、world、renderCount: 2。注意 titleNode 这个"静态节点"从头到尾没有任何代码去更新它，这正是编译器要放大到整棵树的效果。
2.2 第二半：编译器把模板静态分析成"带章"的代码
模板 → AST → transform（判定每个节点的动静）→ codegen，产物里有四样关键优化：
① 静态提升（hoistStatic） 。完全静态的 vnode 被提到 render 函数之外、模块作用域里创建一次。看真实产物（用 @vue/compiler-dom 编译下面模板得到）：
html
<div class="container">
<p>固定文案标题</p>
<p class="desc">{{ msg }}</p>
<button @click="onClick">点我</button>
<ul>
<li v-for="item in list" :key="item.id"
:class="{ active: item.id === selected }">{{ item.name }}</li>
</ul>
</div>编译产物（节选关键结构）：
js
import { createElementVNode as _createElementVNode, toDisplayString as _toDisplayString,
renderList as _renderList, Fragment as _Fragment, openBlock as _openBlock,
createElementBlock as _createElementBlock, normalizeClass as _normalizeClass } from "vue"
const _hoisted_1 = { class: "container" } // 静态 props 对象，创建一次
const _hoisted_2 = { class: "desc" } // 同上，永不重建
export function render(_ctx, _cache) {
return (_openBlock(), _createElementBlock("div", _hoisted_1, [
_cache[1] || (_cache[1] = _createElementVNode("p", null, "固定文案标题", -1 /* CACHED */)),
_createElementVNode("p", _hoisted_2, _toDisplayString(_ctx.msg), 1 /* TEXT */),
_createElementVNode("button", {
onClick: _cache[0] || (_cache[0] = (...args) => (_ctx.onClick && _ctx.onClick(...args)))
}, "点我"),
_createElementVNode("ul", null, [
(_openBlock(true), _createElementBlock(_Fragment, null, _renderList(_ctx.list, (item) => {
return (_openBlock(), _createElementBlock("li", {
key: item.id,
class: _normalizeClass({ active: item.id === _ctx.selected })
}, _toDisplayString(item.name), 3 /* TEXT, CLASS */))
}), 128 /* KEYED_FRAGMENT */))
])
]))
}② 事件缓存（cacheHandlers） 。看产物里按钮那行：_cache[0] || (_cache[0] = (...args) => ...)。事件回调第一次渲染时创建后就被缓存，之后每次 render 复用同一引用。这个细节价值极大：事件函数不再算动态 props，传给子组件时引用永远不变，子组件的 props 对比直接命中"没变化"，整棵子树跳过更新。
③ patchFlag 盖章 。每个动态节点都带一个位掩码，告诉 patch 阶段"你到底哪里会变"：1 TEXT 只变文本、2 CLASS 只变 class、4 STYLE、8 PROPS（props 里有确定的动态键）、16 FULL_PROPS（有动态 key，得全量 diff props）。patch 时按 flag 精准修复，而不是"反正重新 set 一遍 props"。
④ block tree 与 dynamicChildren，这是难点三的解法 。再看产物：_openBlock() / _createElementBlock 成对出现。根节点是一个 block，它把自己内部所有带 patchFlag 的动态后代收集进 dynamicChildren 数组。patch 时拿到一个 block，只遍历它的 dynamicChildren，静态兄弟节点看都不看 。但前面说过，平铺收集遇到 v-if/v-for 会索引错位。Vue 的解法是把"结构可能变化"的位置也变成 block：v-if 的两个分支各自 _openBlock()（见下），v-for 的每一项也自成一个 block。block 的语义是"这里开始结构自洽、内部稳定 "，于是每个 block 内部可以放心按索引对比 dynamicChildren，结构变化被隔离在 block 边界上单独处理（v-if 换分支、v-for 按 key 复用移动）。
用同样的编译器编译一个 v-if，看分支如何各自开块：
html
<div>
<p v-if="ok">yes</p>
<p v-else>no</p>
<p>{{ msg }}</p>
</div>
js
export function render(_ctx, _cache) {
return (_openBlock(), _createElementBlock("div", null, [
(_ctx.ok)
? (_openBlock(), _createElementBlock("p", _hoisted_1, "yes"))
: (_openBlock(), _createElementBlock("p", _hoisted_2, "no")),
_createElementVNode("p", null, _toDisplayString(_ctx.msg), 1 /* TEXT */)
]))
}ok 翻转时，div 这个 block 先处理"分支结构变了"，再进入新分支的内部 block 做靶向对比。结构变化与内容更新被拆成了两层，各管各的。
2.3 两条线如何汇合：一次更新的完整旅程
把上面两块拼起来，走一遍 msg 从 'hello' 变成 'world' 的全程：
- 组件挂载时创建渲染 effect 并首次执行。render 执行到
_toDisplayString(_ctx.msg)，读取触发track，组件 effect 订阅进state.msg的 dep。此时 render 产出的 vnode 树里，div 这个 block 的dynamicChildren只收集到两个节点：那个带1 /* TEXT */的<p>，和v-for分支内的动态部分。 state.msg = 'world'触发trigger，组件 effect 的 scheduler 把它丢进更新队列。同一轮事件里改十个数据也只 flush 一次。- flush 时 render 重跑，生成新 vnode 树。关键在这里 ：patch 入口拿到新旧两个 div block，不逐层 diff 整棵树，而是直接遍历
dynamicChildren按索引配对，命中那个 TEXT 节点，把textContent改成world。静态提升的_hoisted_1还是那个对象、缓存的按钮回调还是那个函数、v-for列表没变就按 key 全量复用，全程没有一次多余的 vnode 创建或属性对比。 - 若此时
list的某一项selected变了，v-for分支内的 li 也是 block，fragment 先按 key 找到那一个 li，再只更新它自己的动态 children。
所以"1000 行列表只更新一行"不是魔法：dynamicChildren 让对比成本从 O(整棵树) 降到 O(动态节点数)，而动态节点数由编译器在模板里数好了。
2.4 反面：为什么手写 render 拿不到这些优化
编译器的信息优势来自模板是一种约束语言 ，结构可静态分析。手写 h() 是任意 JS，编译器无法预知你这次渲染会创建什么结构，patchFlag 全部退化为全量 diff（BAIL）。这正是 Vue 官方坚持推荐 SFC 模板而非手写 render 的底层原因：性能是设计出来的，不是运行时优化出来的。若确有手写必要又对性能敏感，用 v-memo 手动声明依赖数组，把一组动态节点"钉死"，依赖不变则整块跳过。
3. 应用场景
长列表与表格。行结构复杂但更新集中在个别字段（表格里的状态列、实时价格列），block 靶向让每次更新只碰变化单元，行内静态布局零成本。这也是 Element Plus、Naive UI 的大表格组件敢在 Vue3 上做高性能渲染的底气。
高频数据流。实时行情、监控大盘、协作光标这类每秒多次刷新的场景，若更新能被编译器压到少量动态文本节点，主线程压力从"整页 diff"降为"改几段 textContent"，动画与交互不卡。
子组件更新治理 。理解了事件缓存，就能解释一个常见现象：模板里 @click="fn" 传给子组件不会导致子组件无限重渲染，但手写 render 里每次新建箭头函数传给子组件，会因 props 引用变化逼着子组件走一遍更新。生产代码里给子组件传回调，要么走模板要么自己缓存引用。
工程与面试 。阅读 Vue3 产物时，openBlock/createElementBlock 的出现位置就是结构不稳定点；理解它们等于理解 block tree 的边界。实际写法上：v-for 永远带稳定的 key（否则退回 UNKEYED_FRAGMENT 的索引复用，伴随状态错位风险）；v-if 与 v-for 不要放同一元素（Vue3 里 v-if 优先级更高，两个结构指令叠一起会让编译器无从优化，拆层写）；能静态就别动态，静态节点多到一定程度（连续约 20 个以上）编译器还会触发预字符串化，直接整段 innerHTML 一次成型。
4. 总结
Vue3 性能的核心叙事，是运行时与编译器的一次分工：响应式系统负责把"谁变了"收敛到 key，编译产物负责把"改哪里"收敛到节点。前者是 Proxy 依赖收集的精确性，后者是 patchFlag 与 block tree 的确定性，两者在组件 render effect 处合流，产出的效果就是节点级靶向更新。这也回答了它与 React 的根本分野：React 把"少干活"押在运行时调度上，用可中断换取对任意 JS 的宽容；Vue3 把"少干活"押在编译期分析上，用模板约束换取更少的 diff 工作量。两种哲学没有高下，各有代价：Vue 的优化依赖你写模板，React 的自由依赖它更强的运行时。理解到这一层，Day21 的 diff 算法、Day23 的框架性能优化，就都是在给今天这张图补细节。