企业官网建设流程全解析

1. Vue 3 到底改了什么：从设计目标倒推原理

1.1 为什么是重写而不是小修小补

很多朋友第一次接触 Vue 3 时，第一反应是“Vue 2 我还没学明白呢，怎么又开始改”。真去源码里看一圈之后，会发现 Vue 3 不是 Vue 2 的复制粘贴，而是一次从底层设计思路到运行时机制的完整重构。我把这次重构拆成几条主线：响应式、编译、虚拟 DOM、组件化模型，每条主线都对应着 Vue 2 里被诟病已久的痛点。

先说响应式。Vue 2 用的Object.defineProperty，这东西有先天缺陷：它只能拦截对象的读写，新增属性和删除属性它管不了，所以 Vue 2 才需要$set、$delete这种补丁 API。数组的索引更新也是个老大难，只能用改写原型链的方法去补。Vue 3 用数组，就是能直接拦截的内存级代理，这些问题从根上就没法再出现，因为拦截方式是彻底不同的。

再说编译和虚拟 DOM。Vue 2 的 patch 过程是全量 diff，每次更新都要遍历整棵虚拟 DOM 树，虽然虚拟 DOM 本身比直接操作 DOM 快，但当组件树很庞大时，diff 的时间开销也相当可观。Vue 3 在编译阶段就把静态节点和动态节点分开，在运行阶段精准 patch 动态部分，这部分优化思路我在第 4 章展开说。整体设计目标归纳下来，就是“更快更新、更省内存、更好维护”。

1.2 模块化的整体架构：不再是框架，而是一个生态工具集

Vue 3 的源码在目录上就能看出来，它是按模块拆分的：reactivity（响应式）、runtime-core（运行时核心）、runtime-dom（浏览器相关实现）、compiler-core（编译核心）、compiler-dom（模板编译）、sfc-compiler（单文件组件编译）。这种分法带来的好处很实在：不需要依赖 DOM 的环境也能用。比如小程序、原生渲染、测试环境，可以直接打包runtime-core+ 自己的渲染器，而不必带着整个浏览器 DOM 逻辑。

实际工作中这种模块化的价值非常直接。我做过一个某跨平台项目，底层并非标准的浏览器 DOM，却要跑一套类 Vue 的响应式状态逻辑，当时直接把@vue/reactivity单独拉出来用，两百行代码就接上了。像这种“把响应式当独立状态管理库用”的操作，在 Vue 2 是做不到的，因为 Vue 2 的响应式是跟组件实例深度耦合的。

我在看源码时习惯先看 package 的入口文件，再往下钻内部实现。Vue 3 每个包都提供dist下的多种产物格式，比如vue.cjs.js、vue.esm-browser.js，这些产物是同一个源码通过 rollup 插件生成的，阅读的时候不要被文件名绕晕，生产环境用 esm，Node 环境用 cjs，浏览器调试直接用带global的版本就行。

2. 响应式系统：Proxy、依赖收集与副作用调度

2.1 从 getter/setter 到 Proxy：拦截能力的天花板

Vue 3 响应式最核心的 API 是reactive，它内部用的是new Proxy(target, handlers)。Proxy 和Object.defineProperty最大的区别是，它是“对象级别”的拦截，只要对对象的操作，都会经过统一的 handler。比如读取属性走get，修改属性走set，删除属性走deleteProperty，查找属性是否存在走has，遍历对象的 key 走ownKeys。

打个比方：Object.defineProperty像是在每个物件上安排一个保安，他只能看到自己盯着的这件东西；而 Proxy 是在整个仓库门口装了一整套安检系统，任何进出的货品都会被扫一遍。所以新增属性、删除属性这种“原本没盯防”的操作，在 Proxy 下天然就能被捕获。

这里有个容易被忽略的细节：Proxy 的get拦截器在处理嵌套对象时，需要一个“懒代理”但实则是“按需代理”的策略。具体来说，访问state.a.b时，第一次 get 拿到state.a，如果这个a是普通对象，就要在 get 的阶段顺手把它转成响应式代理。这个过程的实现通常会在 getter 中用Reflect.get(target, key)取到原始值，再判断是否对象、是否已被代理，再调用reactive转换。这个设计保证了层层访问对象的深层属性时，都能保持响应式。

有一个实习时特别容易犯的错：直接用new Proxy(target, { get() { return target[key] } })，这样拿到的值是原始对象，不是代理后的响应式对象，修改它永远不会触发更新。正确写法必须统一走Reflect.get，返回前再做一层响应式包裹。这也是为什么 Vue 3 源码里Reflect到处可见的原因。

2.2 依赖收集与 WeakMap 的三层结构

Vue 3 的依赖收集用了一张三层映射表：targetMap（全局唯一）→ 每个响应式对象 → 每个 key → 依赖集合。第一层是 WeakMap，key 是原始的 target 对象，value 是一个 Map；Map 的 key 是属性名（或字符串或 Symbol），value 是一个 Set，Set 里存着所有依赖此属性的 effect。

为什么第一层要用 WeakMap 而不是 Map？因为 WeakMap 的 key 是弱引用，不影响垃圾回收。如果用户代码里不再持有某个响应式对象，Vue 也没有额外引用它，这个对象和他的依赖表会被 GC 正常回收，不会内存泄漏。这一系列设计不是可有可无的“数据结构美学”，而是响应式机制能稳定运行的内存基础。

get拦截器就是做依赖收集的时机，set拦截器是触发更新的时机，这是响应式系统的核心线索。每次执行 effect（渲染副作用、watch回调、computed求值）时，会设置一个全局的当前活跃 effect，然后执行函数内部的取值操作，触发 get 拦截，把当前活跃的 effect 装进对应 key 的依赖 Set。等 effect 执行完毕，取消“活跃标记”。这套逻辑在源码里是一个ReactiveEffect类，核心方法是run和stop。

实际编码时你会发现，在 effect 中访问哪些属性，这个 effect 就会跟哪些属性形成一个依赖集合。代码 A 里 if 分支访问了state.flag，当flag为 false 时不访问state.name，那name变化时就不会触发 A 重新执行。这个“动态依赖”特征是 Vue 响应式与手动事件监听截然不同的地方。

2.3 ref 与 reactive 的边界：什么时候该用什么

ref在 Vue 3 中的实现不是简单的{ value: reactiveObj }。它是一个名为RefImpl的类，内部用对象访问器存储_value。当传入的是基本类型时，直接存储；当传入的是对象时，会用reactive转换为响应式代理存在_value上。每次读取ref.value就走 get，赋值就走 set，同时触发依赖更新。

这里有一个我非常认可的设计细节：为什么ref要搞一个.value包装，而不像 Vue 2 那样 data 的属性直接挂到实例上？因为 JS 的基本类型没有引用传递，不包装就无法拦截。包装成对象之后，.value的读写才有拦截点。虽然模板里会自动解包，不需要写.value，但在 JS 逻辑区必须记住这个规则。

关于用reactive还是ref，我的经验是：如果数据结构是嵌套对象，不涉及解构和传递，那可以直接用reactive；如果这个值会在组合式函数之间传来传去，或者需要被重新赋值，那优先用ref。const state = reactive({ count: 1 })之后把state解构成{ count }，就丢了响应式，这是 Vue 2 时代就有的心智负担，在 Vue 3 里用ref解构才不会断。在 options 里返回的 data 对象，官方最终也会用reactive包装，但组件内部的 ref 完全可以绕开这一层包装，只暴露给模板自动解包。

2.4 调度器与异步渲染：trigger 之后到底发生了什么

很多人以为触发 set 之后，页面立即更新。实际上 Vue 3 做了一个调度器的中间层。effect 触发更新时，会有一个scheduler决定这个 effect 是同步执行还是排队异步执行。对渲染副作用来说，更新是“批量”且“异步”的。

具体流程是：触发 set → 收集所有依赖的 effect → 每个 effect 决定是否入队 → 把任务推进宏任务队列（通常用Promise.resolve().then）→ 下一个微任务里统一执行所有待处理任务。这就是为什么你在同一个事件处理函数里连续修改三次响应式变量的值，页面依然只更新一次。浏览器端表现为，DOM 的更新总在当前事件循环之后。

这也就解释了为什么nextTick还存在。如果你想在修改状态后立即读取“更新后的 DOM”，那么需要在下一个微任务里去读，nextTick本质上就是用Promise.resolve().then实现的。我曾经写过一段测试代码，在watch回调里拿 DOM 高度，不加nextTick时拿到旧值，加了之后才拿到最新值，这个现象跟调度器原理完全对上。

computed 也有自己独立的调度策略。computed 会在依赖变脏时只标记为“脏”，到下次访问时才重新计算，也就是说 computed 是惰性求值的。如果依赖了大量状态但一直没人在模板里读取，它不会重复计算。源码里叫dirty标志位，触发依赖变化时只将 dirty 置为 true，不执行求值函数。这个设计让计算属性在高频依赖场景下非常省性能。

3. 虚拟 DOM 与 diff 算法：从全量比较到动态靶向更新

3.1 虚拟 DOM 的结构和真实 DOM 的映射

Vue 3 的 vnode 结构非常清晰：type（标签名或组件对象或 Fragment）、props、children、key、patchFlag、dynamicChildren等等。其实vnode就是一个 JS 对象。相比真实 DOM，它轻量得多，创建、复制、比较成本都很低。渲染器拿着 vnode 树递归创建 DOM 节点，更新时通过对比新旧 vnode 决定怎么修改 DOM。

关于patchFlag，这是 Vue 3 在编译阶段给动态节点打的标记。比如有一段模板<div :class="cls">{{ text }}</div>，编译之后，这个 vnode 会被打上“需要更新 class”和“需要更新 text”的标记。运行时只要看标记位，就能精确知道这个节点哪些属性是可变的，而不用手动对比 props 里的所有字段。这个机制有不少人误以为只在编译产物中出现，但其实手写h函数时也可以直接附上 patchFlag，只是大多情况下都由编译器生成。

3.2 新旧子节点更新的关键路径

diff 的核心是patchKeyedChildren，处理新旧两个 children 数组。Vue 3 的 diff 算法采取了几步优化策略。

第一步是从头开始同步：两个数组从头逐一对比，相同 key 的节点直接复用，往前走，直到某一方出现不一致就停止。

第二步是从尾开始同步：两个数组从末尾倒着往前对比，相同 key 的节点直接复用，往回走，直到不一致就停止。

第三步是建立未知序列的映射。如果经过前两步还有剩余部分，而且新旧数组长度差异很大，Vue 3 会对旧数组剩余部分建立 key → index 的 Map，然后遍历新数组剩余部分。遇到 key 能在 map 中找到的，说明是同一个节点，需要移动；找不到的，说明是新节点，需要创建。

第四步是最长递增子序列（LIS）。具体到代码中，Vue 3 在重组移动时，先算出新数组在旧数组中的索引序列，再找出其中最长递增子序列。这些索引对应的 DOM 节点保持原位，不在 LIS 中的节点需要移动。这样能把移动次数降到理论最低，因为索引递增的节点相对顺序本来就是对的，不需要来回挪。

每次面试或带新人讲到这里，我都会用一个实际的列表操作来验证：把[A, B, C, D, E]更新成[C, D, A, B, E]。整个过程中只有 A、B 两个节点被移动，C、D、E 位置不变，所以算法会把 sub sequence（旧索引数组[2, 3, 0, 1, 4]）的 LIS 设为[2, 3, 4]，对应新序列的第 0/1/4 位原位保持，只移动索引 2 和 3 的节点。这个例子里两类节点完全对调是最简单的演示，但理解 LIS 的思路比背代码更重要。

3.3 为什么 key 不能乱写：diff 算法的现实约束

diff 能高效运作的前提是 key 能稳定区分节点身份。很多新人用索引 index 作为 key，列表中部插入或删除数据时会出大问题。因为 key 相同的节点会直接复用，如果第一个位置原来是 A，插入 B 之后，B 也拿到 key=0，渲染器会认为 B 就是 A 的更新版本，进而复用旧 DOM，导致内部状态错乱。

正确的 key 应当是业务数据里独有的稳定标识，比如 id、订单号、路由路径等。如果数据没有唯一标识，宁可考虑调整数据结构或使用组合 key（如 id + type），也比在数组内用索引强得多。并且 key 不能直接用随机数，否则每次重渲染都会生成新 key，旧节点无法复用，等于强制全量重建 DOM。

4. 编译优化：Block Tree 与静态提升背后的运行时红利

4.1 编译器在 Vue 3 中的地位

Vue 模块中，编译是在运行时之前的“预处理”步骤。浏览器里运行带 template 的组件时，模板会先被编译成 render 函数，然后再交给运行时挂载。在单文件组件中，这一步通常在构建期用@vue/compiler-sfc完成。你最终在浏览器里下载执行的是编译后的 render 函数，而不是模板字符串，这个过程有点像是把 TypeScript 源码编译成 JS 后运行。让编译承担尽可能多的静态分析，运行时只做必要的动态更新，这是 Vue 3 性能提升最重要的底层因素。

4.2 静态提升：只创建一次，重复使用

在 Vue 2 中，render 函数每次执行都会重建整棵树的 vnode，即使节点完全静态，也要创建一次新的 vnode 对象。Vue 3 的编译器在生成代码时，会把不依赖任何响应式数据的节点直接提取到 render 函数之外，创建一次 vnode 常量，后续重复执行 render 时直接复用。

用一个最简单的例子：

<div> <span>固定文案</span> <span>{{ msg }}</span> </div>

编译后的产物大致是这个风格：

const hoisted = createVNode("span", null, "固定文案") function render(_ctx, _cache) { return createVNode("div", null, [ hoisted, createVNode("span", null, toDisplayString(_ctx.msg)) ]) }

这里的hoisted在模块加载时就已创建，不会在每次 render 时重复 new vnode。这是用空间换时间的做法：静态节点复用 vnode 对象，编译器通过静态分析保证它不会变化，安全性有一定保障。运行时也减少了垃圾回收压力，长列表场景下收益特别明显。

同时，编译器还会对静态字符串或静态 props 做类似处理。比如<div class="foo">中的{ class: "foo" }也可以被提取成常量。在这些没有动态绑定的地方，render 函数每次执行时生成的都是同一个对象引用，省去大量内存分配和比较操作。

4.3 Block Tree：从树的高度上跳过静态分支

Block Tree 是 Vue 3 编译优化最核心的部分。普通虚拟 DOM 呈现为完整树结构，diff 时要遍历全树。Vue 3 的模板编译器会主动标记出“动态节点”并把它们收集成一个动态子节点数组，这种带dynamicChildren的节点就叫 Block。

每个组件的根节点就是一个 Block，内部遇到结构不稳定的节点时，也会生成新的 Block，形成一棵 Block Tree。运行时做 patch 时，只需要对比每个 Block 的dynamicChildren数组，静态节点被完全跳过。因为大多数模板的静态分支占多数，动态点往往只占一小部分，所以 patch 复杂度和动态节点数量成正比，而不是和整棵树的节点数成正比。

有一个经常被问到的问题：为什么需要多个 Block 而不直接用一个大数组收所有动态节点？原因在于结构不稳定。v-if和v-for会导致节点出现或消失、顺序变化，如果所有动态节点放在一个扁平的数组里，这些结构性变化会破坏数组的对应关系，patch 准确性就无法保证。Block 嵌套本质上是把不定结构切分成稳定的小块，每个块内部的动态节点顺序是可预测的，这是 diff 算法能够安全工作的前提。

4.4 PatchFlag 的应用边界与手动标注

模板编译时，每个动态 vnode 会根据动态点的不同，被打上不同的 patchFlag。比如某个节点只有:class是动态的，则标记PATCH_CLASS；只有:style是动态的，则标记PATCH_STYLE；只有文本内容动态，则标记PATCH_TEXT；动态 props 中有多个属性时，则标记PATCH_PROPS并附带dynamicProps列表。

运行时processElement内部会根据 patchFlag 决定走哪个分支：如果是PATCH_CLASS，只更新 class，完全跳过其他 props 比较；如果是PATCH_PROPS，只更新动态 props 列表里的那几项。这比 Vue 2 中每个元素都对新旧 props 做一次遍历的做法，减少了数量级上的无意义比较。

是否有动态节点完全无法被优化？当编译分析不出某个绑定是否静态时，patchFlag 会变成全量标记，不过这种情况在 SFC 模板中很少，应该是手写 render 函数或者片段模板时才会遇到。真遇到性能瓶颈的时候，可以直接打开编译输出，看每个 vnode 的 patchFlag 是否存在，以及dynamicChildren长度是否符合预期，这种源码级排查对优化页面卡顿非常有效。

5. Composition API 与生命周期：原理层面的重新设计

5.1 setup 的执行时机与上下文结构

Composition API 是 Vue 3 另一个标志性变化。从原理上看，setup是在组件实例创建之后、真正挂载 DOM 之前执行的特殊函数。它具体做了什么？用 options API 时，data、methods、computed、watch 这些选项会分门别类地被实例处理；用 setup 时，一个函数里可以用显式的调用来注册这些能力，它更像是一个“把各种能力显式罗列的工厂函数”。

setup执行时返回两种可能：返回对象，这个对象会作为组件渲染上下文的属性暴露给模板；返回函数，这个函数会被视为 render 函数。更关键的是，setup先于beforeCreate生命周期钩子执行，所以在 setup 的时机中，还没有完整的实例上下文（比如this不可用）。这其实规避了 Vue 2 options 阶段中“this 尚未初始化就被使用”的一堆隐式问题。

在意的是响应式依赖的绑定时机：在setup中创建的ref、reactive、computed、watch，都会注册到当前组件实例的 effects 关联中。组件卸载时，这些关联的 effect 都会被自动清理。这是 Composition API 不容易出现“组件已销毁但回调仍在执行”的根本保障。

5.2 为什么生命周期可以直接在 setup 中调用

另一个看上去很神奇的设计是，onMounted可以在setup中任意调用，不需要绑定具体组件。原理上，Vue 3 内部有一个“当前正在初始化的组件实例”的全局变量。在setup执行期间，这个全局变量指向当前组件。onMounted只是把这个回调函数注册到当前实例的生命周期队列中。等挂载完成，实例会逐个执行队列里的回调。

如果是普通的异步函数，在 await 之后调用onMounted，这时组件实例的“当前初始化”标记已经结束，onMounted 就无法被正确注册。因此官方建议生命周期注册不要放在异步代码之后。如果你需要等待接口返回后再执行挂载逻辑，比较稳妥的做法是放在一个由数据驱动的watch里，而不是在异步回调里注册钩子。

5.3 provide/inject、依赖注入与作用域

provide/inject 的实现也依赖于组件实例之间的关系。provide 相当于在当前组件实例上挂一个提供的对象（或重新赋值），inject 则用当前实例向上查找父级实例，找到对应 key 即返回。响应式数据通过 inject 传递时，实际上是因为响应式对象本身的引用保持不变，而非依赖注入机制额外做了代理。有一点容易踩坑：inject 一个ref，在子组件中用.value修改，父组件拿到的也是同一个 ref，因为传的是引用。如果 inject 的是一个普通值，修改子组件中的副本不会影响父组件，这是符合 JavaScript 传值规则的。

6. 从原理到实战：常见问题与排查实录

6.1 响应式失效：我改了数据为什么页面不更新

这是 Vue 3 新手上路最常见的困惑。结合前面讲的 Proxy 拦截原理，可以总结成下面几个典型场景：

• 对reactive对象解构之后直接修改解构变量。

const state = reactive({ count: 0 }) const { count } = state count++ // 页面不更新

• 对整个reactive对象重新赋值。

const state = reactive({ count: 0 }) state = { count: 1 } // 重新赋值的是原始变量，不是代理对象

• 对ref的.value赋一个普通的对象，后续直接修改该对象的属性。

const r = ref({ list: [] }) r.value.list = [1, 2, 3] // 如果 list 一开始不存在，需要手动触发

排查思路很简单：先确认变量本身是否代理对象，再确认是否在 effect / render / watch 中被跟踪。可以在源码中临时打几个console.log来验证 get / set 是否真正被捕获，这种调试法在大型项目里最直观。

6.2 关于 activeEffect 与异步导致的收集丢失

依赖收集依赖一个全局标记，但在异步或者外部库回调中，这个标记可能被重置。在setTimeout里读取响应式变量，此时不在任何 effect 的执行上下文里，读取不会收集依赖。如果某个副作用想跟踪一个定时错误读取到的状态，这不会自动触发。

解决方案是明确的：读操作要放在 Vue 环境可感知的作用域中，也就是放在 computed、watch、render 或普通 effect 内部，不要在裸异步回调中读取。如果必须用定时器，可以使用watch或watchEffect显式包裹，或者在读取前在同步代码中显式创建依赖。

6.3 列表渲染的性能问题：diff 移动和新结构标记

列表重排序的卡顿主要是由 DOM 移动引起的。虽然 LIS 尽可能减少了移动数量，但移动 DOM 本身的开销依然存在。当一个列表有一万个真实 DOM 节点时，即使 diff 算得很快，移动 100 个节点的真实 DOM 操作也会花费超过 10ms，在低端移动设备上可能明显掉帧。

可行的处理策略有几个方向：

• 在业务层优化：用分页、虚拟滚动减少单次渲染节点数。
• 在 key 设计上优化：保证顺序发生变化的节点尽量少。
• 尝试将变动幅度大的业务拆成独立组件：每个组件内部持有自己的渲染器，把问题隔离在局部。

组合式函数常常会在实际项目中带来“所有状态集中在一个大对象”的问题。如果所有模块共享一个reactive大对象，任何属性变化都会导致依赖它的组件全量更新。解决思路是减少共享粒度，把只有局部使用的状态收敛到局部ref里，只有真正跨组件共享的部分才放在顶层。

6.4 使用 Composable 与渲染器的相互作用

组件每次重新渲染时，普通函数中的组合式函数也会重新执行。写组合式函数时，如果函数内部创建ref，它每次渲染都会重新创建，对象引用就变了。这不是 Vue 的 bug，而是 JS 函数语义决定的。如果你希望组合式函数的状态跨渲染保存，那么应该在setup中调用一次并返回一个稳定的对象，而不是每次 render 时都重新调用。

带nextTick的 DOM 测量是一个典型的场景。渲染更新是异步的，直接在修改状态后读 DOM 尺寸，会得到上一次渲染的结果。此时需要await nextTick()之后再读。这套时序非常稳定，原理上就是因为调度器把更新排进了微任务队列。

6.5 性能定位三板斧

遇到页面卡顿，我一般会按三个层次排查：

第一层，控制台看编译产物。如果 render 函数里没有出现hoisted或dynamicChildren，需要确认模板是否真的没用静态节点，或者是否手写 render 函数绕过了编译优化。

第二层，看浏览器 Performance 面板中的 JS 执行时间。如果某一个时间点 JS 执行超过 100ms，多半是组件数量过多或 diff 过大在实时渲染中占比过高，需要优先优化这些区域。

第三层，看网络请求频率和接口数据的响应数据结构。有时候响应式职责是干净的，但一些计算器或调度把大量数据盲目塞进响应式对象，导致 getter 被频繁触发。一个“只读但被反复访问”的数据，可以用markRaw或shallowRef来切断深层响应式转换，这种优化对数据量大的静态配置极其有效。

7. 从原理到工程：Vue 3 源码导读与学习路径建议

7.1 用真实的浏览器环境读源码

读源码时，最推荐的方式是 clone 官方仓库后用npm install安装依赖，然后直接打开packages/vue/examples下的示例页面，在浏览器里打断点调试。尤其实时打断点看 get / set 拦截器，看ReactiveEffect和调度器的执行顺序，比在纸面上看代码理解得要深得多。

调试的入口有两个推荐位置：reactive.ts里的reactive函数和renderer.ts里的patch/processElement函数。把断点打在 patch 处，对比数据更新前后的调用栈，你能直观地看到内部如何把 effect 从依赖收集到调度并最终完成 DOM 更新。这种调试经验在写大型业务组件时，能帮你精准预判哪些地方会导致不必要的重新渲染。

7.2 源码里的设计模式参考价值

即便你不参与 Vue 源码开发，Vue 3 源码本身也是极佳的架构范本。它对“逻辑分层”的把握值得学习：把 reactive 独立出来，使得核心逻辑在不同环境中复用；把编译和运行时拆开，让测试和 debug 更容易；目录命名完全对应模块职责。

packages/runtime-core是跨平台运行时基础，所有跟 DOM 相关的都放进runtime-dom。你在浏览器中调用createApp时，真正起作用的函数其实是ensureRenderer中产生的渲染器。如果在移动端渲染或 Canvas 渲染场景下做定制，可以参考runtime-dom里的nodeOps，替换创建、插入、移除节点的实现，就能复用一个几乎完整的响应式组件模型。

7.3 浏览器 devtools 必备调试技巧

很多人在使用 Vue Devtools 时只看组件树和状态，但漏掉了它提供的“Performance”面板。这个面板可以展示每个组件更新的原因，比如是哪个响应式属性触发了重渲染，耗时多少。借助性能面板，你能定位到是“那次修改”还是“那个组件层级”引起的更新扩散。这样做的效果，比肉眼浏览代码去猜性能瓶颈要高效得多。

有一个我之前在项目中使用过的排查技巧：在模板中临时加入{{ 一些静态文本 }}的节点，然后在 Vue Devtools 的“渲染性能”里看它所在组件是否也参与更新。如果某个静态节点的外层组件频繁更新，说明组件树中响应式依赖的范围太大，考虑拆分或给组件加DefineComponent的显式 props 限制。

7.4 延伸阅读：从 Vue 3 原理到周边生态

理解 Vue 3 原理，不止是理解这个框架本身。路由和状态库的源码也大量用到响应式和生命周期。Pinia本质上是用reactive+Computeds实现的 store。路由的currentRoute是一个shallowRef，页面切换本质上是改变一个响应式值后触发组件更新。这些周边的源码配合 Vue 3 核心原理看，你会越来越体会到“既然响应式已经能表达状态，那么绝大多数状态管理都可以建立在这一层之上”。

Vite 作为构建工具，和 Vue 3 的模块设计有天然契合。开发阶段用 ESM 直接预构建依赖，省去打包步骤；生产环境才做完整构建。理解 Vue 3 的模块打包机制，可以帮助你在配置vite.config.js时知道哪些依赖可以 external，哪些必须预构建，进一步优化首屏加载性能。比如@vue/shared等内部工具的代码会被打进最终包，但如果你配置了 external 来减小 vendor 体积，要注意 Vue 的各包版本必须保持匹配，避免两份代码产生不同的响应式标记。

8. 项目实战中的一些长期经验

8.1 从 Vue 2 迁移时的原理性踩坑

迁移项目时最大的坑不是语法差异，而是响应式边界变了。Vue 2 里很多“隐性依赖全局状态”的写法在 Vue 3 中可能直接失效。比如一个 watch 监听this.$store.state.count，在 Vue 2 中对象属性被劫持后，watch 可以感知；Vue 3 中如果 store 是用reactive构建的，读取属性和深度访问者的依赖就会自动收集，但这个收集只发生在同步执行上下文中。如果 store 使用ref包裹且是在异步逻辑中访问，依赖收集可能缺失。

此外，组件复用和类型定义也更容易出现边界问题。Vue 3 + TypeScript 下，defineProps编译阶段的类型推断比 Vue 2 的props运行时校验要严格得多。团队协作时如果某个 props 类型写错，Vue 3 在编译阶段就会报错，而不是运行时才发现。这要求迁移时对组件的 props 定义做一次全面梳理，能提前暴露不少隐性 bug。

8.2 关于使用 h 函数与手写 render 的实践

手写render函数虽然能完全绕开模板编译，但也绕开了 Block Tree 和静态提升的优化。你几乎无法手动为每个 vnode 打上正确的 patchFlag。所以除非做高阶动态组件（比如渲染函数式组件），否则尽量使用模板。模板就是 Vue 3 的性能保证，手写 render 是“下位替代”。

真需要手动控制动态节点时，可以用createVNode的第五个参数 type 直接传 patchFlag，也可以借助withDirectives把一些指令逻辑作为运行时扩展注入 vnode，但这个复杂度对绝大多数业务没必要。日常使用 SFC 模板，让编译器接管优化。

8.3 从维护角度理解设计取舍

整套 Vue 3 的设计，本质上是在“减少不必要的工作”。很多评论说 Vue 3 “运行时更复杂了”，复杂是复杂在框架内部自动做的事情更多，拿到开发者手里的体验反而是更简单的：不需要$set、不需要手动优化整棵树的对比、不需要关心静态节点重复创建。

One of the最明显的体验就是，代码中不再出现与 DOM 细节耦合的繁琐操作。比如数据数组的变更，在 Vue 2 时代要考虑“是否触发数组检测”的问题，Vue 3 完全恢复成了“改动数据即改动状态”的心智模型。这种回归背后是 Proxy 机制作为底层逻辑支点可以兼容所有一般的修改方式。

8.4 一个问题：为什么数据变化的更新是异步的

这个问题看似简单，但很容易被忽略。异步批量更新的收益是很明显的：如果每次赋值都触发一次渲染，那种连续改动多个状态的操作会产生大量不必要的 DOM 操作，浪费时间也增加抖动。把多个更新合并成一次渲染，而且只发生在同一个事件循环内，这是用户体验和性能的双重优化。

对业务代码的影响是：所有依赖时间顺序的逻辑，必须在异步之后读取 DOM。最好用watch/watchEffect在数据变化之后统一处理，而不是在赋值之后立刻同步读取 DOM。这种编码习惯一旦建立，你在复杂的动画与数据协同任务中会轻松很多。

9. 一些小建议与目前的使用心得

读到这里的读者，应该不是只想了解一两个 API 的用法，而是真正对“原理”感兴趣。我的建议是，学习 Vue 3 原理时不要逐行背诵源码，而是带着问题去读：

• 修改一个响应式数据之后，框架从触发到 DOM 更新到底经过几条路径？
• 编译器对自己模板生成了哪些 patchFlag？动态消费者为什么存在？
• 一个组件的 setup 和 render 在生命周期中的位置，具体是在哪个阶段执行的？

我在实际项目中，最受益的并不是能背诵源码的某一行代码，而是能快速定位“当前这个页面卡顿，是哪个环节的瓶颈”的能力。这种能力只能通过把源码作为调试工具来使用，在真实场景中不断验证。

还有一个建议：多看其他框架的实现。Vue 3 的响应式思想和 React 的重新渲染模型是两种相反的思路。React 是“外部驱动”的：状态更新后，框架重新执行组件函数得到新视图，再 diff；Vue 是“内部追踪”的：依赖数据被修改后，仅对应的副作用自动更新。理解了这两种思路的差异，你在设计大型应用的状态结构时会有更清晰的取舍意识。

技术是在不断迭代的。早年间我在 Vue 2 中习惯了各种补丁写法，依赖 Vue 3 后最大的变化之一，就是终于可以不依赖补丁 API 写应用代码了。整体上来看，Vue 3 的每一项机制设计都在为“复杂度隔离”服务，源码中很多微小细节，比如 WeakMap 的选择、Block 的设计，都是这种思路的具体体现。掌握这些原理，不只是让你会写一个框架，更能让你在处理复杂业务时，从表层代码看到底层运行的逻辑脉络。这种能力，对长期深耕前端开发的朋友来说，是实打实的护城河。

最后分享一个我常用的调试小技巧：在node_modules/@vue/runtime-core/dist/runtime-core.esm-bundler.js里的patch函数加一个断点，然后触发一次更新。仔细观察调用栈，你会发现每次更新时被唤醒的 effect、动态节点对比和属性更新之间的关系是那么清晰。多断点几次，原来懵懵懂懂的逻辑就会成体系地连起来，那种顿悟感，真的很值得你花一个下午去体验。