知其然，更要知其所以然。在深入Vue3源码之前，我们需要先回答一个问题：Vue3为什么值得重写？
前言
2020年9月，Vue 3.0 正式发布。
距离 Vue 2.0 发布已经过去了整整四年。四年时间，对于一个前端框架来说，几乎是"一代人"的代际更迭。这四年里，React Hooks 革了类组件的命，TypeScript 从小众变成了标配，IE 浏览器终于被微软自己判了死刑。
在 Vue 开发中，很多同学可能会有疑问：
"Vue2 我用得挺好啊，为什么要学 Vue3 ？"
"Composition API 不就是把 options 改成了 setup 吗？"
"Vue3 性能提升真的有那么明显？"
如果你也有类似的困惑，那么这篇文章正是为你准备的。
作为《Vue3 源码解析》专栏的开篇，我不会直接贴大段源码，而是想先和你聊聊：
Vue2 到底哪里"痛"了？Vue3 是怎么治这些"痛"的？以及，我们为什么要花这么长的时间去研读源码？
Vue2 的"遗产"与"包袱"
首先必须承认：Vue2 是一个极其成功的框架。
2016年，React 如日中天，Angular2 刚发布，前端正处于"三国杀"的混沌期。Vue2 凭借更低的入门门槛、清晰的 API 设计、完善的官方生态，硬生生杀出一条血路，成为国内前端的事实标准。
但成功也意味着"包袱"：
痛点1：响应式系统的"先天残疾"
我们在使用 Vue2 时，对于以下几个响应式丢失场景一定不会陌生：
常见响应式丢失场景
场景1：新增属性不响应
this.obj.newProp = 'value' // 不是响应式的
// 解决方案：Vue.set(this.obj, 'newProp', 'value')
// 或者：this.$set(this.obj, 'newProp', 'value')
场景2：数组索引赋值不响应
this.arr[0] = 'new' // 不是响应式的
// 解决方案：this.arr.splice(0, 1, 'new')
场景3：数组length修改不响应
this.arr.length = 0 // 不是响应式的
为什么会出现响应式丢失？
Vue2 的响应式数据设计，是基于 Object.defineProperty 这个 API 的，它只能拦截对象已有属性的 get/set 方法，对于新增属性、删除属性、数组索引赋值等操作，它根本监听不到。因此，Vue2 必须额外提供 Vue.set、Vue.delete 等方法，还要重写数组的 7 个变异的方法。
更为致命的是性能问题：Vue2 在初始化时，需要递归遍历 data 的所有嵌套属性，挨个调用Object.defineProperty。如果我们的 data 是一个深度 10 层、每层 100 个属性的大对象，初始化时就要执行上万次 defineProperty。
注：这是一个O(n)的刚性开销，无法优化。
痛点2：Options API 的"碎片化"
随着组件规模增长，Vue2的 Options API 会呈现一种"碎片化"的形态：
export default {
data() {
return {
// A功能的数据
// B功能的数据
// C功能的数据
}
},
computed: {
// A功能的computed
// C功能的computed
},
methods: {
// B功能的方法
// A功能的方法
// C功能的方法
},
watch: {
// B功能的watch
// A功能的watch
}
}
即：同一个功能的代码被强制拆散到不同选项中，而不同功能的代码却被揉在一起。
当我们维护一个数百行、甚至数千行的组件时，需要在 data、computed、methods、watch之间反复横跳时，这种"碎片化"就成了沉重的认知负担。
当然，Vue2 的开发团队也意识到了这个问题，所以他们推出了 Mixins 的解决方案，但又带来了命名冲突、来源不透明、隐式依赖等一系列新的问题。
痛点3："大而全"的打包体积
Vue2 是一个典型的 Monolithic 架构：
import Vue from 'vue'
// 加入我只想用响应式系统，但Vue构造函数包含了：
// - 模板编译器
// - 过渡系统
// - 组件系统
// - 指令系统
// - 插件系统
// - ...
即使你只用了 Vue2 中 5% 的功能，打包时也必须得带上 100% 的代码。这在 Webpack 时代尚可接受，但在"秒级HMR"、"按需加载"成为标配的今天，这种设计显得格外笨重。
痛点4：TypeScript的"二等公民"
Vue2的代码库是用 JavaScript 写的，TypeScript 支持是通过额外的声明文件"打补丁"。这就会导致很多场景下，this 的类型推导会"迷路"：
export default {
data() {
return {
count: 0
}
},
methods: {
increment() {
this.count // 这里count的类型是any
}
}
}
Vue3的"顶层设计"
面对这些痛点，Vue3 团队做了一个极其大胆的决定：
不是修修补补，而是重写整个框架。
从2018年立项到2020年发布，Vue3经历了：
- 100% TypeScript 重写，类型推导不再是问题。
- Monorepo架构重构，核心功能拆分为独立包。
- 响应式系统完全替换，Proxy 取代 defineProperty。
- 编译器重写，支持更激进的编译时优化。
- 虚拟 DOM 算法重写，引入 Patch Flags。
设计目标1：更底层的响应式能力
Vue3的响应式系统基于Proxy，实现了真正的"全能力"拦截：
const state = reactive({
obj: { count: 0 },
arr: [1, 2, 3]
})
// 新增属性 - 响应式
state.obj.newProp = 'value'
// 数组索引赋值 - 响应式
state.arr[0] = 100
// 数组length修改 - 响应式
state.arr.length = 0
// 删除属性 - 响应式
delete state.obj.count
// Map/Set/WeakMap/WeakSet - 全部支持
const map = reactive(new Map())
更重要的是性能维度的变革：
- Vue2：初始化时递归所有属性，O(n)刚性开销
- Vue3：只在
get时进行深层代理，O(k)按需开销
这意味着：如果我们的组件渲染只访问了 data 中的5个属性，Vue3 就只对这5个属性进行响应式处理。在大型数据表格、长列表渲染场景下，这种惰性策略能带来数倍乃至数十倍的性能提升。
设计目标2：逻辑复用的"第一等公民"
Composition API 不是把 options 改成 setup 这么简单，它提供了一套完整的逻辑组合机制：
// 这是一个纯粹的逻辑单元
function useUserList() {
const users = ref([])
const loading = ref(false)
const fetchUsers = async () => {
loading.value = true
users.value = await api.getUsers()
loading.value = false
}
return { users, loading, fetchUsers }
}
// 使用时像搭积木一样组合
export default {
setup() {
const { users, loading, fetchUsers } = useUserList()
const { visible, open, close } = useModal()
return { users, loading, fetchUsers, visible, open, close }
}
}
每个功能单元都是独立的函数，输入输出清晰，没有命名冲突，没有来源歧义。这才是 Composition API 的本质：让逻辑复用成为"第一等公民"。
设计目标3："拆开卖"的模块化架构
Vue3 采用 Monorepo 架构，将核心功能拆分为 30 多个独立包：
packages/
reactivity/ # 独立的响应式系统
runtime-core/ # 运行时核心
runtime-dom/ # DOM平台实现
compiler-core/ # 编译器核心
compiler-dom/ # DOM平台编译
vue/ # 完整版本
这意味着，我们在使用时可以按需引入，可以只引入响应式系统 @vue/reactivity，也可以只引入编译优化 @vue/compiler-dom 。
这种架构带来了惊人的 Tree-shaking 效果：
- Vue2完整包：约22.5KB（gzipped）
- Vue3完整包：约16.5KB（gzipped）
- Vue3核心运行时：约11.75KB（gzipped）
减少了41%的体积，这还只是开箱收益。
Vue3性能突破的"三大引擎"
如果说 Vue2 是一辆皮实耐用的家用轿车，Vue3 就是一架精密调校的赛车。它不是靠单一技术点取胜，而是系统工程式的全面优化。
引擎1：响应式系统重构
Vue3官方基准测试显示：
- 组件初始化速度：提升约55%
- 更新性能：提升约133%
- 内存使用：减少约54%
这些性能提升，不只是靠"优化技巧"得来的，而是架构层面全面重构的降维打击。
引擎2：编译时优化
Vue2 的优化主要在运行时，编译器的工作相对简单。Vue3 的编译器则极其"聪明"：
静态提升：不变的节点（静态节点）只创建一次
// 编译前
<div>
<span>静态文本</span>
<span>{{ dynamic }}</span>
</div>
// 编译后（简化）
const _hoisted_1 = createVNode('span', null, '静态文本')
// 这个节点被提升到函数外部，只会创建一次，每次渲染复用同一个VNode
Patch Flags：精确标记动态节点
createVNode('div', null, [
_hoisted_1, // 静态节点，完全跳过diff
createVNode('span', { class: ctx.class }, null, 2 /* CLASS */)
], 4 /* STABLE_FRAGMENT */)
编译器会在生成的代码中插入标记：2 表示只有 class 可能变化，4 表示子节点结构稳定。渲染器看到这些标记，就能跳过绝大部分 diff 工作。
引擎3：Tree-shaking友好
Vue3 的所有 API 都是通过具名导出提供的：
import { reactive, computed, watch, nextTick } from 'vue'
现代构建工具可以静态分析哪些导出被使用了，而那些没有被使用的 API，会在打包时被完全删除。
为什么要研读源码？
1. 解决问题的能力
在以前遇到问题时，尤其是一些诡异问题，比如数据更新不触发页面渲染，我的排查方式是：百度 / Google + AI ，然后复制答案。 现在我的排查方式是：打开源码 → 搜关键函数 → 看依赖收集条件 → 定位问题 → 解决问题。
2. 面试的"认知差"
很多面试者在聊 Vue3 响应式时会说："Vue3 用 Proxy 代替了defineProperty"。
如果我们能接着说："Proxy 的13种拦截方法中，Vue3 实际使用了get、set、has、deleteProperty、ownKeys 这 5 种，其中 ownKeys 是为了拦截 for...in 循环..."——这就是认知差。
3. 技术决策的底气
只有当我们研读完源码之后，才能对这门技术知根知底：
Vue3 的响应式系统是'拉'式的，数据变化后框架知道具体哪些组件需要更新；React 是'推'式的，需要手动shouldComponentUpdate 或 useMemo。所以在高频更新场景，Vue3 性能更稳定；在超大应用中，React 的手动优化上限更高。
结语
2019年初，尤雨溪在Vue3 RFC阶段写过这样一段话：
"We are not trying to win the framework war. We are trying to build something that we ourselves would enjoy using for the next 5 years."
"我们不是在试图赢得框架战争，我们只是想构建一个自己未来5年愿意愉快使用的东西。"
Vue3 不是对 Vue2 的否定，而是 Vue.js 这个项目进入"成熟期"后的自我迭代。
它告诉我们：即使是成功的软件，也有必要不断反思自己"哪里不够好"。
这也是我开设这个专栏的初衷——不是背诵源码，而是在Vue3的源码里看到一个优秀的设计是如何逐步演进的。
对于文章中错误的地方或者有任何问题，欢迎在评论区留言讨论！
