企业官网建设流程全解析

开头

Vue核心(二)这个标题，说实在的，刚看到的时候我愣了一下。网上聊Vue的教程千千万，但真正把“核心”讲透的其实不多。大多教你怎么写组件、怎么配路由、怎么上状态管理，却很少解释背后的那套机制到底是怎么转起来的。我在这行干了十几年，从jQuery时代一路走过来，Vue 2刚出的时候就在项目里用了，后来Vue 3带着Composition API横空出世，我也算是一路踩坑踩过来的。这篇博文，我打算换个思路：不教你怎么写业务代码，专门聊聊Vue背后的几大核心机制——响应式系统的底层原理、虚拟DOM和diff的来龙去脉、模板编译那点事，以及Vue 2到Vue 3到底改了什么、为什么这么改。适合那些已经能熟练写Vue组件，但总觉得“哪里不太对劲”“搞不懂原理”的朋友来看。看完之后再去写代码，你会有一种从“照着抄”到“我知道自己在干嘛”的感觉。

1. 响应式系统：从Object.defineProperty到Proxy的本质区别

1.1 什么是数据驱动视图，响应式系统到底解决什么问题

前端框架的核心理念就是“数据驱动视图”。说白了，数据变了，页面就得跟着变，你不用手动去操作DOM。响应式系统就是实现这个“自动跟着变”的后台机制。

Vue 2和Vue 3的响应式原理有个根本区别：Vue 2用的是Object.defineProperty来拦截对象属性的读写，Vue 3用的是ES6的Proxy。这个差异不是小事，它决定了整个框架的能力边界。

先说Vue 2。Object.defineProperty的优点是对ES5环境的兼容性很好，但它有个天然的缺陷：只能拦截单个属性的读取与写入。也就是说，你给一个对象定义响应式属性，必须一个个属性去定义。所以Vue 2在初始化数据时，会递归遍历整个data对象，给每个属性都加上getter和setter。这就会带来几个问题：

• 对象新增属性不是响应式的，所以Vue 2才提供了Vue.set或this.$set这个API来手动添加响应式属性
• 数组的索引操作（比如arr[0] = xxx）没法被拦截，所以Vue 2重写了数组的7个方法（push、pop、shift、unshift、splice、sort、reverse）
• 深层对象的递归遍历在初始化时有明显的性能开销

Vue 3改用Proxy之后，这些问题基本都被解决了。Proxy拦截的不是“对象上的某一个属性”，而是“对对象的整个操作”。不管是读取任何一个属性、写入任何一个属性、删除属性、还是调用in操作符，都可以被统一拦截。而且Proxy的拦截是惰性的——你没访问到那个嵌套对象时，它不会被递归处理，这样初始化性能也更好。

这里我打个比方：Object.defineProperty就像你在一栋楼里每个房间门口都安排一个保安，你想监控谁就得在他门口站着；而Proxy就像你在整栋楼的大门口安排了一个总闸，任何人进出都要过这道闸。效率和信息量完全不是一个量级。

1.2 依赖收集与派发更新的完整链路

响应式系统光能拦截数据读写还不够，它还必须搞清楚两件事：谁在用这些数据、数据变了该通知谁。这就是“依赖收集”和“派发更新”机制。

我拆开来说。你在组件里写：

computed: { fullName() { return this.firstName + ' ' + this.lastName } }

当fullName这个计算属性第一次被访问时，它内部的this.firstName会触发firstName的getter。这个getter就会把“当前正在计算的这个函数”登记为firstName的依赖。怎么登记？每个属性都维护一个依赖集合（在Vue 3里叫作dep，内部是一个Set结构），把使用到这个属性的副作用函数（比如组件的渲染函数、计算属性函数、侦听器）都装进去。等到firstName被修改时，setter触发，它就去遍历自己那个依赖集合，逐个通知它们“你依赖的数据变了，请重新执行”。

这个机制就是Vue高性能的关键：只有真正被模板或计算属性使用到的数据，才会建立依赖关系。没被使用的数据，你改一万次它也不会触发任何更新。

Vue 3里这个机制的实现代码相对清晰一些，核心的类我简单列一下：

// Vue 3响应式核心的极简示意 let activeEffect: ReactiveEffect | null = null class ReactiveEffect { constructor(public fn: () => void) {} run() { activeEffect = this this.fn() activeEffect = null } } function track(target, key) { if (activeEffect) { let depsMap = targetMap.get(target) if (!depsMap) { depsMap = new Map() targetMap.set(target, depsMap) } let dep = depsMap.get(key) if (!dep) { dep = new Set() depsMap.set(key, dep) } dep.add(activeEffect) } } function trigger(target, key) { const depsMap = targetMap.get(target) if (!depsMap) return const dep = depsMap.get(key) if (dep) { dep.forEach(effect => effect.run()) } }

这里有个细节值得注意：track函数的执行条件是“当前存在活跃的副作用函数”。也就是说，读取数据这个动作本身不会被收集，只有在“某个副作用函数执行过程中”读取的数据才会被收集。这个设计很精妙，它保证了依赖的准确性。

1.3 响应式系统的常见陷阱与实操避坑

这个机制理解透了，很多开发中遇到的“怪问题”就都有了解释。我挑几个高频的坑来聊。

第一个坑：直接给响应式对象添加新属性。Vue 2的解决方案是用this.$set，Vue 3虽然Proxy能拦截新增属性，但如果你用reactive创建的是一个普通对象，新增属性倒没问题；如果你用了ref包裹一个对象，然后给ref.value新增属性，也没问题。真正容易踩坑的是：你用reactive创建的对象，在模板中直接渲染新增属性，本地开发环境一切正常，一旦上了生产环境，万一遇到冻结对象之类的情况，还是会出问题。稳妥的做法是，尽量在设计数据结构时就预留好所有字段，而不是动态添加。

第二个坑：数组的响应式。Vue 2重写了数组方法，但arr[0] = xxx这种索引赋值依然无法触发更新。虽然Vue 3用Proxy解决了这个问题，但很多团队还在维护Vue 2的老项目，这个坑仍然真实存在。

第三个坑：解构丢失响应式。这个好多新手都上过当。const { count } = toRefs(props)还是const { count } = props，前者是响应式的，后者不是。原因是解构出来的count就是一个普通变量，拷贝的是值，不是引用。同理，你在setup里从reactive对象解构出某个属性，这个属性也会丢失响应性。

第四个坑：深层对象的性能。Vue 2初始化data时递归遍历所有层级，如果一个对象层级特别深，初始化就会卡顿。Vue 3的Proxy虽然是惰性拦截，但如果你在代码里频繁访问深层嵌套属性，也会产生一定的proxy层层包裹开销。这算是一个折中，实践中并不会有多大影响，但追求极致性能的场景需要注意。

说实话，理解响应式原理之后，很多面试题都能迎刃而解，更重要的是排查线上问题会快很多。很多组件明明数据变了但视图没变，第一反应就是去看数据是否是响应式的、依赖是否被正确追踪，而不是盲目加key或者强制刷新。

2. 虚拟DOM与diff算法：框架为什么需要这么个中间层

2.1 虚拟DOM解决了什么问题，它和真实DOM是什么关系

直接操作真实DOM是昂贵的。浏览器的DOM操作会触发重排（reflow）和重绘（repaint），频率一高页面就开始卡。但有经验的开发者都知道，并不是所有DOM操作都慢，慢的是那些无脑触发大面积重排的操作。虚拟DOM的初衷，就是尽量减少对真实DOM的操作次数。

虚拟DOM是一个普通的JavaScript对象，用它可以描述一个DOM节点的类型、属性和子节点。比如：

// 一个描述 <div class="app"><span>hello</span></div> 的虚拟DOM const vnode = { type: 'div', props: { class: 'app' }, children: [ { type: 'span', props: {}, children: 'hello' } ] }

每次数据变化时，框架先创建一份新的虚拟DOM树，再和上一次的虚拟DOM树对比，找出差异，最后把差异一次性批量更新到真实DOM上。这样避免了多整页重建，也把多次小更新合并成一次大更新。

为了避免重复创建VNode，Vue 3里还实现了VNode的复用机制。同一个组件如果渲染了多次，它们的VNode是可以共享的。这个细节很多教程没讲，但它对框架性能有一定贡献。

2.2 Vue 2的双端diff与Vue 3的快速diff对比

diff算法是整个虚拟DOM的核心。Vue 2和Vue 3的diff策略有很大不同。

Vue 2的双端diff，核心思路是：在新旧两个子节点列表的头尾各放一个指针，从两端同时向中间收敛，比较新旧头节点、新旧尾节点以及交叉节点，尝试找到可以复用的节点，然后进行移动或删除。这种算法在处理“头尾移动”这种场景时效率很高，因为不需要遍历整个列表。

Vue 3的快速diff在此基础上做了升级。它先做前置和后置的相同节点处理，再处理中间区域。对于中间区域的节点，它用了一个Map来做key到索引的映射，然后基于最长递增子序列来最小化移动次数。这个过程用到了贪心加二分查找，时间复杂度优化到了O(nlogn)。

我举个例子来说明两种算法的差异。假设你有一个列表[A, B, C, D]，更新后变成[C, D, A, B]。Vue 2的双端diff会通过头尾指针的移动，发现头节点A和旧尾节点D不匹配，旧头节点A和新尾节点B匹配，于是移动了节点，做了几次操作之后完成。Vue 3的快速diff会先处理前置相同节点（没有），后置相同节点（A、B和旧列表的A、B匹配，但位置不同，所以也不会直接跳过），然后进入中间区域处理。最终两种算法都能正确更新，但Vue 3在大型列表中的移动次数往往更少。

用表格对比一下：

我个人体验是，日常业务中两者差异感知并不明显。真正的差异在几千上万个节点的大列表滚动场景里才会体现出来。所以不需要因为性能差异去纠结哪个版本更好，更重要的还是在于框架的整体一致性。

2.3 key的真正作用：为什么不要用index作为key

很多初学者不理解，为什么列表渲染的时候要用key，以及为什么不能用index当key。有人会说“我用了之后功能没问题啊”。其实从diff的角度非常容易解释。

key的作用是标识一个节点的身份。diff进行到复用节点这一步时，它会优先判断key是否相同。如果key相同，就认为两个节点是同一个组件或同一种元素，只需要更新属性；如果key不同，那就直接放弃复用，创建新节点替换旧节点。

用index做key的问题在于，当列表顺序变化（比如排序、在头部插入）时，索引对应的项也变了。原本在第一个位置的组件A，现在变成了组件B，但它们的key都是0，diff就会认为这是同一个组件，于是只是更新属性，而不是更换组件。这会带来很多隐蔽的问题，比如输入框内容错乱、组件内部状态没被重置、动画错乱等。

最典型的场景是：一个列表里有输入框，你往头部插入一条数据，index会整体后移，每个输入框都“保持”了自己原来输入的内容，但看起来内容却整体错位了。用id或者业务上唯一标识作为key，就没有这个问题。

这里再补充一点：Vue 3里，如果没有设置key，框架会用节点的索引作为默认key，而且这个默认key是“就地复用”的，它并不会强制组件重新创建。所以为了性能还是为了状态正确性，都建议在列表循环里写key。

关于key的注意事项还有一些经验：

• key必须是稳定、唯一的，不要用随机数，否则每次渲染创建的key都不同，会导致组件频繁销毁重建
• key只在列表循环场景有必要其他地方加key没有实际价值，只会增加diff的负担
• 如果列表里只有一个元素，有没有key问题都不大，但保持习惯就好

3. 模板编译：从template字符串到真实DOM的完整工序

3.1 编译的三阶段：parse、transform、generate

模板编译是Vue把template字符串变成渲染函数的过程。这个过程分成三个阶段：parse（解析）、transform（转换）、generate（生成）。

parse阶段，编译器会把模板字符串解析成AST（抽象语法树）。AST就是一棵描述模板结构的树，每个节点包含标签名、属性、指令、子节点等信息。比如：

<div class="app"> <span>{{ msg }}</span> </div>

解析出来的AST大致长这样：

{ type: 1, tag: 'div', attrs: [{ name: 'class', value: 'app' }], children: [ { type: 1, tag: 'span', children: [ { type: 2, expression: 'msg', content: '{{ msg }}' } ] } ] }

transform阶段，编译器对AST进行一些额外的处理。Vue 3在这里做了很多优化工作，比如标记静态节点、动态节点，生成patchFlag（补丁标记），这样在运行时diff的时候可以直接跳过静态内容，只对比有标记的动态部分。

generate阶段，编译器把处理好的AST生成渲染函数代码。这个函数在运行时会被执行，返回VNode树，最终渲染成真实DOM。

要求是：理解这三个阶段的作用对于排查问题很有帮助。比如你发现某个模板写错了但编译没报错、运行却表现异常，就得回到编译层面去找问题；又比如你在模板里用了还没定义的变量，编译能不报错但运行时会报错，这也是编译期和运行期分离的表现。

3.2 静态标记与PatchFlag的优化思路

Vue 3的编译优化有一个很核心的设计：patchFlag。它做的事情是，在编译阶段就分析出模板中哪些地方是静态的、哪些地方是动态的，然后在生成的代码里记录这些信息。

比如这样一个模板：

<div> <span>静态文字</span> <span>{{ count }}</span> </div>

编译后，第二个span节点会带上一个patchFlag，标记它的文本内容可能变化。运行时，diff只需要对带标记的节点做检查，静态节点直接跳过。对于动态绑定属性的节点，也会打上不同类别的flag，比如PROPS表示属性可能需要更新。这使得Vue 3在更新性能上比Vue 2有了质的飞跃。

与之配套的还有一个Block Tree的概念。编译器会把模板拆分成一个个Block，每个Block内部动态节点会被收集到一个数组里。这样diff的时候，只需要对比这个“动态节点数组”就行了，不用重新对比整棵树。

这个优化思路特别适合那些“页面主体基本不变、只有局部数据在变”的场景。比如管理后台的详情页、电商详情页的图文模块，这些页面往往有大量静态内容，Vue 3的静态标记让它们的更新成本变得很低。

但要注意，这个优化对完整版Vue（运行时+编译器）有效，对预编译的场景（比如使用构建工具+模板预编译）效果一样。如果是运行时编译（比如通过new Vue直接传template），编译发生在浏览器端，性能会差一些，这也提醒我们尽量使用单文件组件（.vue）和预编译的方式。

3.3 运行时编译与预编译的取舍

Vue框架有两种编译模式：完整版（vue.esm.js）和运行时版（vue.runtime.esm.js）。完整版自带了编译器，可以在浏览器运行时把template字符串编译成渲染函数；运行时版不包含编译器，只支持渲染函数。

在浏览器里编译模板是有性能代价的，所以生产环境推荐使用预编译。在使用单文件组件和构建工具时，模板会在打包阶段就被编译成渲染函数，打包后的代码里不会有模板字符串，运行时只需执行渲染函数生成VNode即可。

这里给一句话总结：能用构建工具预编译就尽量不要用运行时编译，后者在编译阶段会消耗额外的浏览器资源，也会让包体积变大。

4. 组件机制与通信方案：从设计意图看组件到底怎么回事

4.1 组件实例的生命周期是响应式系统与DOM更新的调度中枢

组件是Vue应用的基本单元。一个组件实例从创建到销毁，会经历一系列生命周期钩子：beforeCreate、created、beforeMount、mounted、beforeUpdate、updated、beforeUnmount、unmounted（Vue 3的叫法）。

有些初学者不理解为什么要有这么多生命周期钩子，正常理解就是“在组件不同阶段插入你自己的逻辑”。但从底层来看，这些钩子实际上是框架调度流程的关键节点。比如组件首次挂载时，会执行mount流程：创建组件实例、初始化数据、设置响应式系统、生成渲染函数、创建VNode、挂载到真实DOM。整个过程会有多个可插入的钩子点。

Vue 3的Composition API里，生命周期钩子改成了函数式写法，比如onMounted(() => {})。这些函数必须在setup期间调用，目的是把回调函数注册到当前组件实例上。这里有一个很容易踩的坑：如果你在setTimeout或异步回调里调用onMounted，Vue 3会报警告，因为组件实例上下文已经丢失。

另外要说的是，生命周期钩子也是响应式系统的一部分。beforeUpdate和updated这两个钩子，是在组件发生更新时被调用的。更新的触发方式本质上就是：组件的渲染函数执行时访问的响应式数据发生变化，触发依赖更新，进而调度组件重新渲染。

4.2 组件通信的几种方式与适用场景

Vue组件通信方式很多，新人容易迷。我按使用频率和适用场景分一下类：

• props / emits：父组件向子组件传数据、子组件向父组件发事件。这是官方推荐的基础方式，适合层级关系简单、通信逻辑不复杂的场景
• v-model：语法糖，本质就是props + emit的组合。适合实现组件内部可控的双向绑定
• provide / inject：跨层级传递数据，适合深层嵌套的父组件向多个后代组件共享数据，比如主题配置、用户信息。注意，provide/inject不是响应式的，除非你传入的是ref或reactive对象
• EventBus / mitt：跨组件通信，适合非父子关系的平级组件。Vue 3已经不再提供$on、$off，常见做法是引入第三方事件库
• Vuex / Pinia：状态管理库，适合中大型应用，全局共享状态。Vue 3生态里Pinia越来越成为主流
• 模板refs（ref属性）：获取组件实例或DOM节点，适合需要直接操作子组件时的场景，但不要滥用

我个人的体会是，通信方案选型要遵循“能少用就少用”的原则。小型应用里只要props和emits就能解决90%的需求。很多项目一上来就全局状态管理，结果团队里每个人写代码都往store里放数据，代码越来越难维护。

4.3 v-model的底层本质

v-model是Vue一个非常有特色的语法糖，它让表单元素和组件都能轻松实现双向绑定。它的本质其实很简单：

<input v-model="searchText" />

等价于：

<input :value="searchText" @input="searchText = $event.target.value" />

对于组件而言，v-model绑定的是组件的modelValueprop和update:modelValue事件。这个设计从Vue 3开始统一了，之前Vue 2中v-model默认绑定的prop是value，事件是input。Vue 3支持一个组件上使用多个v-model，只需要指定参数名，比如v-model:title="pageTitle"。

这里有个实用技巧：如果要实现一个封装了输入框的组件，可以用defineModel宏来快速实现双向绑定。这个宏是Vue 3.4之后引入的，它简化了“定义一个prop，然后在某个事件里emit更新”的过程。

理解v-model的本质，能帮你避开一个经典坑：在子组件里直接修改props并在模板上展示这个prop值，结果发现本地修改立即生效，但父组件的状态没变，下次父组件重新渲染又把子组件的值覆盖回去。这就是因为你改的是“传进来的值”，不是“改变传进来的值的手段”。

5. Vue 2到Vue 3的核心演进：不只是API变了

5.1 Composition API到底解决了什么问题

Composition API是Vue 3最重要的API变革。很多从Vue 2过来的朋友第一反应是“为什么不直接沿用Options API”，其实这个设计合理得很。

Options API把代码结构拆成了data、methods、computed、watch几个固定的区块。当组件小的时候，这个拆法清晰易懂；但当组件大起来，一个问题相关的逻辑会被拆散到data、methods、computed、watch各个区块中。比如一个搜索功能，data里存了searchText和searchResults，methods里有handleSearch和resetSearch，computed里有hasResult，watch里有对searchText的侦听。这些逻辑散布在Options API的各个区块里，维护起来非常累。

Composition API把这些逻辑聚合在一起，你可以在setup函数里把某个功能相关的数据、计算属性、侦听器、生命周期钩子全部写在一块。这样代码的“内聚性”大幅提升，重构和复用也更容易。Vue官方还提供了useXxx这种“组合式函数”的模式，把一坨相关逻辑抽离成独立函数，这是Options API完全做不到的。

我在迁移项目的时候有一个明显的感受：用Options API写的2000行组件，迁移到Composition API之后，往往能瘦身到1200行左右，而且每个功能块都更容易被独立理解和测试。

5.2 生命周期与全局API的变化

Vue 3的另一个大变化是全局API的调整。Vue 2里的Vue.component、Vue.mixin、Vue.prototype等，在Vue 3里被替换成了一套链式调用的app对象：

// Vue 2的做法 Vue.component('my-component', MyComponent) Vue.prototype.$http = http // Vue 3的做法 const app = createApp(App) app.component('my-component', MyComponent) app.config.globalProperties.$http = http

这个改动的好处是，多个Vue实例可以共存，不会互相污染全局配置。Vue 2是单例的，如果你在页面上手动创建了多个Vue根实例，它们的全局配置是共享的，方法很容易互相覆盖。Vue 3的app实例互相隔离，组件注册、全局配置都只对当前app实例生效。

生命周期的映射也有所调整。以卸载为例，Vue 2的beforeDestroy和destroyed在Vue 3中改名成了beforeUnmount和unmounted。捕获错误时，errorCaptured、renderError虽然语义上保留了，但Vue 3提供了更完善的app.config.errorHandler来统一处理。

如果是从Vue 2迁移到Vue 3，最常见的工作就是：把全局API调用方式改成app实例的方式，把filter（Vue 3删除了过滤器）改成函数调用，把$on/$off改掉。这个成本其实不小，所以很多老项目都停在了Vue 2版本。

5.3 虚拟DOM与框架演进方向

看完Vue 2到Vue 3的演进，我们能隐约看出前端框架的发展方向：编译时做更多优化、运行时做更少的无用功。

Vue 3的编译优化（静态标记、Block Tree、patchFlag）本质上是把“哪些地方可能变”这件事提前到了编译期。运行时只需要按图索骥，处理那些确实需要更新的动态部分。React也在做类似的事情，例如React Compiler尝试在编译期自动记忆组件，减少重复渲染。

对开发者而言，认知上有一个重要的转变：框架的性能优化越来越依赖编译期分析，所以写模板的时候要尽量“老实”——不要做太多动态操作，不要把所有内容都写成动态渲染，让编译器有机会做静态标记。

我不太建议去背性能优化策略表，而是推荐你带着“编译期到底看到了什么”的视角去写模板。比如一个纯静态的页面骨架，编译器能很轻松地标记它为静态VNode；而如果你在模板里到处写函数调用、动态表达式，编译器就无法优化，运行时代价自然就上去了。

6. 常见问题与排查技巧实录

6.1 响应式失效排查：数据改了，视图没变

这类问题出现的频率极高。我的排查步骤通常是这样：

第一步，先确认数据本身是不是响应式的。用reactive创建的对象，或者ref创建的变量，都应该能被isReactive或isRef检测到。如果你用的是普通对象或基本类型变量，那自然没有响应性。

第二步，确认修改的方式是否被响应式系统监听。Vue 2时代，新增属性、索引赋值都是经典的失效场景；Vue 3虽然Proxy能拦截大部分操作，但如果你用一个新对象整体替换了reactive对象的某个属性，可能也会因为失去依赖追踪而失效。

第三步，确认你修改数据的地方是否在副作用函数的执行上下文中。比如说你在某一个异步回调里修改了ref的值，这个异步回调不是由渲染函数触发的，修改后依然会触发更新吗？答案是会，因为ref的更新机制不依赖“谁在修改”，它只需要“修改动作本身能够触发对应依赖的更新”。

第四步，确认是不是组件没触发重新渲染。有的场景下，数据修改确实被追踪到了，但组件的render函数并没有被执行，原因可能是你修改的响应式数据和“组件真正访问的数据”不是同一个。这个情况特别容易发生在使用props解构并传给computed时。

6.2 组件重新渲染的无效成本：依赖追踪的范围

组件重渲染其实是有成本的。如果组件的渲染函数里访问了很多响应式数据，那这些数据中任何一个变化都会导致整个组件重新渲染。所以一些库会提供shouldUpdate、memo等机制来减少重渲染。Vue 3的响应式系统本身已经足够精确，但如果你在一个大组件里把整个store都引入渲染函数，那任何store变化都会带动这个组件更新。

实践中我的建议是：组件拆分细一点，粒度小一点。把需要频繁动态变化的部分拆成子组件，让父组件的渲染尽量“静态化”。这不是框架的问题，是设计的问题。

6.3 编译检查与运行时错误速查

这里整理一个常见问题速查表：

这些问题的共性教训是：遇到问题先把“响应式链路”画出来，再把“编译产物”过一遍，往往就能定位到具体原因。不要一上来就怀疑框架有bug，Vue在这方面是久经考验的。

我做前端这么多年，Vue前前后后用了两个大版本。刚开始用Vue 2的时候，我就发现一个很有意思的现象：如果你完全理解了响应式系统和组件的生命周期，很多框架层面看起来“玄学”的问题其实都是可推演的。所谓“Vue核心”，说到底就是理解数据流在组件里的传递路径、数据变化如何被追踪、组件如何被创建和销毁。把这些搞清楚了，写代码的自信程度完全不一样。

最后分享一个小技巧：排查响应式问题时，可以在项目里临时开启Vue 3的app.config.performance = true，它会输出组件更新的性能追踪。再看浏览器性能面板的User Timing，你能直观看到哪些组件在频繁更新、每个更新花了多少时间。这比靠猜要快得多。对于准备深入研究Vue源码的人来说，我建议你从reactive的实现开始读，它是最独立也最能体现设计思想的一部分。读完再看编译和运行时调度，整条链路就会豁然开朗。