简介对 Vue3 与 TypeScript 结合开发感兴趣的前端开发者这份源码学习资源提供了从基础语法到工程实践的完整参考。资源共 2002 个文件以 Markdown 笔记、JavaScript/TypeScript 源码和 JSON 配置为主压缩包约 63MB其中 1042 份 md 文档用来讲解核心概念与实现思路803 份 js 文件包含可运行的示例代码或源码片段147 份 json 文件演示项目配置与数据结构。内容覆盖 Vue3 Composition API 的灵活组件逻辑组织、TypeScript 接口与泛型带来的类型约束、Vuex/Pinia 状态管理方案、Vue Router 路由配置以及 Ant Design Vue 等 UI 库的接入实践方便读者按模块查阅并结合源码理解设计思路。无论是刚接触 Vue3 的新手还是需要从 JavaScript 转向 TypeScript 的开发者都可以从这些分类笔记和源码示例中获得直接帮助。已有 570 人学习下载适合正在进阶 Vue3、希望用 TypeScript 重构或规范化前端项目的开发者作为参考资料。 很多人问我“Vue3我用得挺熟了TypeScript也写了一年多怎么一翻开源码还是像看天书”这个问题我太有感触了。答案往往不是你不懂Vue3而是你还没摸清Vue3背后的那套TypeScript玩法。Vue3源码本质上是一本TypeScript高级用法的活教材只不过它顺带实现了一个前端框架。掌握了它的阅读方法你会发现之前那些零散的TS知识、Vue3面试题、生命周期疑惑全都被串起来了。这篇文章不是逐行注释源码而是我啃完Vue3核心模块之后整理出来的一套“从业务开发思维切换到源码阅读思维”的路线。会覆盖环境准备、createApp入口、响应式系统、computed联动调度、diff优化这几块每一块都尽量讲清楚“为什么这么设计”。适合想把Vue3源码当作TS练功场、想搞懂面试题底层逻辑、或者准备基于Vue3做二次封装的同学。1. 为什么说读Vue3源码本质是在读TypeScript1.1 Vue3源码里那些最容易劝退的TS写法我第一次打开Vue3源码时第一反应是“这真的是我写的那种TypeScript吗”。满屏的extends、infer、keyof、Conditional Type还有大量as const和函数重载。业务项目里可能一年都用不上几次的泛型嵌套在源码里像呼吸一样自然。举一个最简单的例子ref函数在源码里的定义是这样的export function refT extends RefUnwrapBailTypes( value: T ): RefT export function refT(value: T): RefUnwrapRefT export function refT any(): RefT | undefined export function ref(value?: unknown) { return createRef(value, false) }这不是在炫技而是为了让开发者在使用ref时能得到精确的类型推导。第一个重载处理特殊类型第二个处理普通类型并自动拆包第三个处理无参数场景。读源码时如果看不懂这种重载写法后面寸步难行。还有一个很劝退的写法是infer关键字比如Vue3里判断一个类型是否被readonly包裹时用的DeepReadonly大量依赖infer U来提取类型参数。我的建议是啃源码前先花一周把TypeScript的泛型、条件类型、infer、keyof、索引类型这几块吃透不用全会但至少要能看懂“这个类型在提取什么信息”。这比背任何Vue3面试题都值。1.2 环境准备本地调试Vue3源码的最小配置读源码最忌讳“只读不跑”。纯靠眼睛扫代码很多逻辑关联是看不出来的。我建议用Vite搭一个最小的调试环境直接把Vue3源码作为依赖跑起来。# 创建基础项目 npm create vitelatest vue3-source-debug -- --template vue-ts cd vue3-source-debug npm install接着做两件事第一在vite.config.ts里配置别名让项目直接指向本地克隆下来的Vue3源码包第二打开.vue文件后在ref、computed、reactive这些API上打断点通过浏览器Sources面板直接看调用栈。这样你能看到createRef怎么被调用、track在哪一行触发、trigger如何进入调度器——比干读代码高效十倍。TypeScript本身的配置也需要注意。Vue3源码用的是moduleResolution: bundler或node你本地项目的tsconfig.json最好保持一致否则类型定义可能解析不到。还有热词里提到的“baseUrl已弃用7.0会停止运行”这个警告新版TypeScript里建议直接用paths配合moduleResolution: bundler不要再用baseUrl。2. 从createApp起步看懂应用启动的全链路2.1createApp那张庞大的调用关系网很多人看Vue3源码不知道从哪里下手我的建议永远是从createApp开始因为它是一个应用的出生点一条线串起整个框架。业务代码里你写createApp(App).mount(#app)好像很简单但源码里这一行至少做了四层事情createApp内部通过ensureRenderer()拿到渲染器渲染器由createRenderer创建内部包含render、hydrate等核心函数createAppAPI返回真正的app对象这个对象上有mount、component、directive、use等方法mount在拿到根组件后先创建vnode再走render(vnode, rootContainer)完成首次渲染。这里特别值得注意的一点是createRenderer和createApp分离的设计。Vue3把“运行时核心”和“DOM操作”完全解耦所以vue/runtime-core可以脱离浏览器运行vue/runtime-dom才负责具体的节点增删改查。这也是为什么Vue3能很容易地支持vue-native、taro这类跨端方案——端差异被隔离在渲染器接口后面了。2.2 TypeScript在应用入口处设计的“类型安全契约”读createApp源码你会发现Vue3对类型安全的追求是刻进骨子里的。最典型的就是App对象的类型定义它通过泛型把组件的实例类型传给了应用上下文export interface AppHostElement any { version: string config: AppConfig useExtension extends object( plugin: PluginExtension ): AppHostElement component(name: string): Component | undefined componentT extends Component( name: string, component: T ): this mount( rootContainer: HostElement | string, isHydrate?: boolean ): ComponentPublicInstance }这个设计的精妙之处在于当你app.component(my-comp, MyComp)注册组件后TypeScript能立刻知道app实例上多了一个组件名当你在app.config.globalProperties上挂自定义属性时通过ComponentCustomProperties接口做声明合并页面上所有组件的this都能正确推导。这背后用到的就是TypeScript的声明合并特性。对比Vue2和Vue3在入口上的差异Vue2的new Vue({...})是基于构造函数Options里写什么全靠约定Vue3的createApp(App).mount(#app)则是一套有类型约束的组合式API。这个差异表面上是API变化本质是Vue在TS类型系统上做的重构。理解了这一点很多“Vue2和Vue3区别”面试题的答案就能从记忆题变成推理题。3. 响应式系统的底层拆解ref和reactive是怎么被“看见”的3.1 Proxy之上的依赖收集从一行track说起Vue3的响应式系统核心在vue/reactivity包代码不多但非常精练。整个系统就围绕三件事读取时收集依赖修改时触发更新基于调度器控制更新时机。运行时最核心的是track和trigger两个函数。当你在组件里读取ref.value会触发proxy的get拦截进入track把当前正在运行的effect也就是副作用组件渲染函数就是一个effect记录到这个key对应的依赖集合中。当修改值的时候set拦截器触发trigger把依赖集合里所有effect拎出来执行或排队执行。用TypeScript简化后的最小实现大致长这样type DepsMap MapPropertyKey, Dep type Dep SetReactiveEffect const targetsMap new WeakMapobject, DepsMap() let activeEffect: ReactiveEffect | undefined export function track(target: object, key: unknown) { if (!activeEffect) return let depsMap targetsMap.get(target) if (!depsMap) targetsMap.set(target, (depsMap new Map())) depsMap.set(key, activeEffect.deps) } export function trigger(target: object, key: unknown) { const depsMap targetsMap.get(target) if (!depsMap) return const effects depsMap.get(key) effects.forEach(effect effect.run()) }这里有几个关键点WeakMap做外层容器key是原始对象这保证了对象不可枚举时可被垃圾回收。Dep用Set结构是为了自动去重。而activeEffect这个全局变量是Vue3实现“当前活跃副作用”的小技巧执行effect前把它设置为自身执行完还原——这套机制也被React的很多库借鉴了。3.2ref和reactive的类型差异为什么ref要拆包这一块是两个热词——“vue3 computed”和“vue3 ref”——经常连带被问到的原因。reactive只接受对象内部用new Proxy直接代理ref却能接受原始值靠的是一个名为RefImpl的类把值包在.value里同时对对象类型自动调用reactive转换。源码里RefImpl的简化版本export class RefImplT { private _value: T private _rawValue: T public dep: Dep public readonly __v_isRef true constructor(value: T, public readonly __v_isShallow false) { this._rawValue value this._value toReactive(value) } get value() { trackRefValue(this) return this._value } set value(newVal) { if (hasChanged(newVal, this._rawValue)) { this._rawValue newVal this._value toReactive(newVal) triggerRefValue(this) } } }为什么ref要单独搞一个对象而不是直接返回proxy答案是基本类型没有引用可言如果不加一层对象包裹就没办法在多个地方共享同一个响应式值。const a ref(1)之后你在任意组件里改a.value所有引用它读取的地方都感知得到。reactive则天然只适合对象因为对象本身就是引用传递。在TypeScript类型上ref自动拆包UnwrapRef的设计也是精髓。模板里直接用count不需要写count.value因为模板编译器和类型定义都做了自动拆包处理。这个设计让开发体验和类型安全同时得到兼顾——但如果你直接读源码里的UnwrapRef类型会发现它用条件类型加递归写了好长一串这恰恰是理解TS泛型递归的最佳教材。4.computed的联动更新源码里最精妙的调度链路4.1computed只在需要时才计算lazy effect的核心computed是Vue3里我最推荐的源码阅读模块因为代码量少、逻辑闭环、而且涉及了响应式系统的全部核心概念。先看它的类型签名export function computedT( getter: ComputedGetterT ): ComputedRefT export function computedT( options: WritableComputedOptionsT ): WritableComputedRefT实现上computed内部创建了一个ComputedRefImpl它继承自RefImpl的响应式能力但有两个独特之处一是脏值检查二是延迟更新。用生活化的比喻computed像一个精明的账房先生你问他账目时他才算一遍算完记住结果只有在他记账时用了的那些原始账本发生变化时他才会把记录标记为“需重新计算”但此时还不动手等你真正来问的时候再算。4.2track、trigger、scheduler三者如何组成调度链路看computed源码时最重要的两个字段是_dirty和effect。_dirty标记当前值是否过期effect负责收集依赖。核心代码简化后是export class ComputedRefImplT { public dep?: Dep private _value!: T public readonly __v_isRef true public readonly [ReactiveFlags.IS_READONLY]: boolean public _dirty true public effect: ReactiveEffect constructor(getter, private readonly _setter, isReadonly) { this.effect new ReactiveEffect(getter, () { if (!this._dirty) { this._dirty true triggerRefValue(this) } }) } get value() { trackRefValue(this) if (this._dirty) { this._dirty false this._value this.effect.run() } return this._value } set value(newValue) { this._setter(newValue) } }这里最精妙的是scheduler回调当computed依赖的响应式值变化时并不会立刻设置_dirty false并重新计算而是先设置_dirty true然后主动触发依赖computed的effect。这个设计把“无效计算”省掉了如果多个依赖值在同一轮里变化computed只需标记一次脏值最后一轮统一重算即可。举个例子computed依赖a和b某次操作连续改a、b、a三次。如果是Vue2的纯watcher玩法可能要重复计算多次Vue3靠_dirty标记真正计算只发生一次。这就是为什么Vue3的computed在复杂派生状态场景下比Vue2明显更流畅的核心原因。4.3 面试常问的“computed和watch区别”源码阶段怎么答很多Vue3面试题会让你区分computed和watch。如果你只背“computed是计算属性watch是监听器”那只能拿基础分。从源码层面两者的本质区别是computed内部创建的是一个惰性effect只有读取.value时才执行getterwatch内部创建的是立即或按选项执行的effect不是惰性的。computed暴露的是值供模板或其他状态直接引用有缓存watch暴露的是回调不产生新值只做副作用处理没有缓存概念。computed的更新是“拉取式”的由读取方触发watch的更新是“推送式”的由源变化主动触发。理解这一点后你会发现两者不是可以随便替换的关系模板依赖优先用computed异步操作、DOM操作、状态联动优先用watch。写业务代码时判断逻辑会清晰很多。5. 组件更新与diff优化静态提升、patchFlag、最长递增子序列5.1 Vue2和Vue3 diff的核心差异从双端对比到快速对比diff算法是Vue源码阅读绕不开的硬骨头。Vue2的双端diff四个指针对比已经够让人头疼Vue3在此基础上又做了不少优化。热词里提到的“静态提升、patchFlag、最长递增子序列”就是Vue3优化的三驾马车。先看静态提升。模板里不绑定数据的节点Vue2在每次重新渲染时都会重新创建vnodeVue3在编译阶段把这些节点提升到render函数外部变成常量只创建一次。例如div classcontainer span固定标题/span span{{ dynamicText }}/span /divVue3编译后的render函数大致会变成const _hoisted_1 createElementVNode(div, { class: container }, [ _createElementVNode(span, null, 固定标题, -1 /* HOISTED */) ]) export function render(_ctx, _cache) { return (_openBlock(), createElementBlock(Fragment, null, [ _hoisted_1, createElementVNode(span, null, toDisplayString(_ctx.dynamicText), 1 /* TEXT */) ])) }注意那个-1和1这就是patchFlag编码。静态节点标记为-1表示永远不会变化动态节点标记为1表示只需要比较文本内容。运行时拿到这些标记后可以精准跳过大量无用对比。5.2 patchFlag如何让运行时“开挂”patchFlag不是玄学它就是编译阶段生成的一个数字位图。每个二进制位代表一种更新类型比如flag值含义1动态文本只需要比较text2动态class4动态style8动态props非class/style64稳定片段子节点不需要diff128带key的片段256非响应式节点静态提升运行时patchElement函数拿到新旧vnode后先比较patchFlag再根据flag类型决定走哪段更新逻辑。这样避免了对每个props做全量diff。编译期静态分析 运行期位掩码判断这是Vue3模板整体性能优于Vue2的关键。这里给一个阅读建议打开 Vue3模版编译器在线演示 写几个常见的模板片段对比编译产物。看多了之后你对Vue模板编译的理解会比干读源码深刻得多。5.3 最长递增子序列移动DOM最少的数学解法Vue3 diff里最难啃的是带key列表的diff核心算法是“最长递增子序列Longest Increasing Subsequence”。它的作用是当新旧两个子节点数组对应起来后找出那些在顺序上已经保持相对稳定的节点通过移动其他节点来达到新顺序让移动次数最少。源码里这一段的核心是getSequence函数function getSequence(arr: number[]): number[] { const p arr.slice() const result [0] let i, j, u, v, c const len arr.length for (i 0; i len; i) { const arrI arr[i] if (arrI ! 0) { j result[result.length - 1] if (arr[j] arrI) { p[i] j result.push(i) continue } u 0 v result.length - 1 while (u v) { c (u v) 1 if (arr[result[c]] arrI) { u c 1 } else { v c } } if (arrI arr[result[u]]) { if (u 0) p[i] result[u - 1] result[u] i } } } u result.length v result[u - 1] while (u-- 0) { result[u] v v p[v] } return result }这个函数的输出是一组下标表示“不需要移动的节点在旧列表中的位置”。剩下的节点才需要被移动或新建。阅读时不需要手推每一行重点是搞清楚它为什么用贪心 二分查找贪心保证新加入的节点尽量小让递增序列能容纳更多元素二分查找保证查找插入位置是O(n log n)而不是O(n²)。建议配合可视化diff工具一起看。盯动画几十遍后“最长递增子序列”这个概念就不再是面试题里的纸面名词而是肌肉记忆。6. 源码学习路线图与避坑建议6.1 按什么顺序读源码最省力我的阅读顺序供参考按“从入口到核心从单一到联动”工具层先把vue/shared里常用工具函数过一遍比如isObject、isString、hasChanged。这些都是基础判断不涉及复杂逻辑能快速建立信心。响应式层读vue/reactivity的reactive、ref、computed、effect四个模块。这是最核心、也是最独立的模块不需要依赖其他包。运行时层顺着createApp进入vue/runtime-core对照vnode、component、scheduler逐个攻破。编译器层最后看vue/compiler-core的模板编译流程理解patchFlag是怎么生成的。每一层都建议配一个最小的Vite项目做联调调试。在源码对应的文件里打断点配合console.trace()看调用链比对着代码空想要快得多。6.2 我踩过的几个坑提前帮你排掉第一个坑是直接啃打包后的单文件。打包产物做了大量变量重命名和压缩很多函数名对不上源码直接看dist文件基本等于浪费时间。正确做法是把Vue3仓库clone下来通过别名指向/packages/*/src/index.ts源码入口用Vite启动项目直接解析TS源码。第二个坑是容易被__DEV__条件分支误导。源码里头大量if (__DEV__)包着warning和校验逻辑这些代码在开发模式才执行生产模式会被摇树优化掉。阅读时最好跳过避免被提醒信息干扰主线逻辑。我的习惯是一看到__DEV__、__TEST__之类的标记直接划过去。第三个坑是忘了看vue/shared里的辅助类型。里面有很多类型工具比如UnionToIntersection、LooseRequired等它们被大量引用在组件props、inject等类型推导里。不搞懂这些工具类型很多类型声明会显得像天书。6.3 源码学到的东西如何反向赋能业务开发最后说点实在的。源码学习最直接的好处是你在业务代码里能做出更适合团队的封装。比如你理解了computed的_dirty机制后设计复杂表单的派生状态时会主动避开“实时计算”的写法改用computed惰性求值。你理解patchFlag的意义后写模板时会更自然地用v-once、v-memo做性能优化而不是盲目加key。我个人体会是源码帮我树立了一个标准一个好的前端抽象一定要做到编译期和运行期分工明确。Vue3把静态分析留给编译器把动态更新交给运行时的位掩码判断这套思路直接影响了我在业务里做配置化渲染引擎的设计方式——能编译期确定的就不要留到运行期。啃Vue3源码这件事短期内看起来性价比不高但它是少数能同时打通TypeScript高级技能、框架设计思想、性能优化思路三个维度的学习素材。希望这份路线能帮你绕过那些我走过的弯路把源码读成自己的底层能力。本文还有配套的精品资源点击获取 Vue3源码阅读指南：TypeScript高级玩法与响应式、diff机制解析
简介对 Vue3 与 TypeScript 结合开发感兴趣的前端开发者这份源码学习资源提供了从基础语法到工程实践的完整参考。资源共 2002 个文件以 Markdown 笔记、JavaScript/TypeScript 源码和 JSON 配置为主压缩包约 63MB其中 1042 份 md 文档用来讲解核心概念与实现思路803 份 js 文件包含可运行的示例代码或源码片段147 份 json 文件演示项目配置与数据结构。内容覆盖 Vue3 Composition API 的灵活组件逻辑组织、TypeScript 接口与泛型带来的类型约束、Vuex/Pinia 状态管理方案、Vue Router 路由配置以及 Ant Design Vue 等 UI 库的接入实践方便读者按模块查阅并结合源码理解设计思路。无论是刚接触 Vue3 的新手还是需要从 JavaScript 转向 TypeScript 的开发者都可以从这些分类笔记和源码示例中获得直接帮助。已有 570 人学习下载适合正在进阶 Vue3、希望用 TypeScript 重构或规范化前端项目的开发者作为参考资料。 很多人问我“Vue3我用得挺熟了TypeScript也写了一年多怎么一翻开源码还是像看天书”这个问题我太有感触了。答案往往不是你不懂Vue3而是你还没摸清Vue3背后的那套TypeScript玩法。Vue3源码本质上是一本TypeScript高级用法的活教材只不过它顺带实现了一个前端框架。掌握了它的阅读方法你会发现之前那些零散的TS知识、Vue3面试题、生命周期疑惑全都被串起来了。这篇文章不是逐行注释源码而是我啃完Vue3核心模块之后整理出来的一套“从业务开发思维切换到源码阅读思维”的路线。会覆盖环境准备、createApp入口、响应式系统、computed联动调度、diff优化这几块每一块都尽量讲清楚“为什么这么设计”。适合想把Vue3源码当作TS练功场、想搞懂面试题底层逻辑、或者准备基于Vue3做二次封装的同学。1. 为什么说读Vue3源码本质是在读TypeScript1.1 Vue3源码里那些最容易劝退的TS写法我第一次打开Vue3源码时第一反应是“这真的是我写的那种TypeScript吗”。满屏的extends、infer、keyof、Conditional Type还有大量as const和函数重载。业务项目里可能一年都用不上几次的泛型嵌套在源码里像呼吸一样自然。举一个最简单的例子ref函数在源码里的定义是这样的export function refT extends RefUnwrapBailTypes( value: T ): RefT export function refT(value: T): RefUnwrapRefT export function refT any(): RefT | undefined export function ref(value?: unknown) { return createRef(value, false) }这不是在炫技而是为了让开发者在使用ref时能得到精确的类型推导。第一个重载处理特殊类型第二个处理普通类型并自动拆包第三个处理无参数场景。读源码时如果看不懂这种重载写法后面寸步难行。还有一个很劝退的写法是infer关键字比如Vue3里判断一个类型是否被readonly包裹时用的DeepReadonly大量依赖infer U来提取类型参数。我的建议是啃源码前先花一周把TypeScript的泛型、条件类型、infer、keyof、索引类型这几块吃透不用全会但至少要能看懂“这个类型在提取什么信息”。这比背任何Vue3面试题都值。1.2 环境准备本地调试Vue3源码的最小配置读源码最忌讳“只读不跑”。纯靠眼睛扫代码很多逻辑关联是看不出来的。我建议用Vite搭一个最小的调试环境直接把Vue3源码作为依赖跑起来。# 创建基础项目 npm create vitelatest vue3-source-debug -- --template vue-ts cd vue3-source-debug npm install接着做两件事第一在vite.config.ts里配置别名让项目直接指向本地克隆下来的Vue3源码包第二打开.vue文件后在ref、computed、reactive这些API上打断点通过浏览器Sources面板直接看调用栈。这样你能看到createRef怎么被调用、track在哪一行触发、trigger如何进入调度器——比干读代码高效十倍。TypeScript本身的配置也需要注意。Vue3源码用的是moduleResolution: bundler或node你本地项目的tsconfig.json最好保持一致否则类型定义可能解析不到。还有热词里提到的“baseUrl已弃用7.0会停止运行”这个警告新版TypeScript里建议直接用paths配合moduleResolution: bundler不要再用baseUrl。2. 从createApp起步看懂应用启动的全链路2.1createApp那张庞大的调用关系网很多人看Vue3源码不知道从哪里下手我的建议永远是从createApp开始因为它是一个应用的出生点一条线串起整个框架。业务代码里你写createApp(App).mount(#app)好像很简单但源码里这一行至少做了四层事情createApp内部通过ensureRenderer()拿到渲染器渲染器由createRenderer创建内部包含render、hydrate等核心函数createAppAPI返回真正的app对象这个对象上有mount、component、directive、use等方法mount在拿到根组件后先创建vnode再走render(vnode, rootContainer)完成首次渲染。这里特别值得注意的一点是createRenderer和createApp分离的设计。Vue3把“运行时核心”和“DOM操作”完全解耦所以vue/runtime-core可以脱离浏览器运行vue/runtime-dom才负责具体的节点增删改查。这也是为什么Vue3能很容易地支持vue-native、taro这类跨端方案——端差异被隔离在渲染器接口后面了。2.2 TypeScript在应用入口处设计的“类型安全契约”读createApp源码你会发现Vue3对类型安全的追求是刻进骨子里的。最典型的就是App对象的类型定义它通过泛型把组件的实例类型传给了应用上下文export interface AppHostElement any { version: string config: AppConfig useExtension extends object( plugin: PluginExtension ): AppHostElement component(name: string): Component | undefined componentT extends Component( name: string, component: T ): this mount( rootContainer: HostElement | string, isHydrate?: boolean ): ComponentPublicInstance }这个设计的精妙之处在于当你app.component(my-comp, MyComp)注册组件后TypeScript能立刻知道app实例上多了一个组件名当你在app.config.globalProperties上挂自定义属性时通过ComponentCustomProperties接口做声明合并页面上所有组件的this都能正确推导。这背后用到的就是TypeScript的声明合并特性。对比Vue2和Vue3在入口上的差异Vue2的new Vue({...})是基于构造函数Options里写什么全靠约定Vue3的createApp(App).mount(#app)则是一套有类型约束的组合式API。这个差异表面上是API变化本质是Vue在TS类型系统上做的重构。理解了这一点很多“Vue2和Vue3区别”面试题的答案就能从记忆题变成推理题。3. 响应式系统的底层拆解ref和reactive是怎么被“看见”的3.1 Proxy之上的依赖收集从一行track说起Vue3的响应式系统核心在vue/reactivity包代码不多但非常精练。整个系统就围绕三件事读取时收集依赖修改时触发更新基于调度器控制更新时机。运行时最核心的是track和trigger两个函数。当你在组件里读取ref.value会触发proxy的get拦截进入track把当前正在运行的effect也就是副作用组件渲染函数就是一个effect记录到这个key对应的依赖集合中。当修改值的时候set拦截器触发trigger把依赖集合里所有effect拎出来执行或排队执行。用TypeScript简化后的最小实现大致长这样type DepsMap MapPropertyKey, Dep type Dep SetReactiveEffect const targetsMap new WeakMapobject, DepsMap() let activeEffect: ReactiveEffect | undefined export function track(target: object, key: unknown) { if (!activeEffect) return let depsMap targetsMap.get(target) if (!depsMap) targetsMap.set(target, (depsMap new Map())) depsMap.set(key, activeEffect.deps) } export function trigger(target: object, key: unknown) { const depsMap targetsMap.get(target) if (!depsMap) return const effects depsMap.get(key) effects.forEach(effect effect.run()) }这里有几个关键点WeakMap做外层容器key是原始对象这保证了对象不可枚举时可被垃圾回收。Dep用Set结构是为了自动去重。而activeEffect这个全局变量是Vue3实现“当前活跃副作用”的小技巧执行effect前把它设置为自身执行完还原——这套机制也被React的很多库借鉴了。3.2ref和reactive的类型差异为什么ref要拆包这一块是两个热词——“vue3 computed”和“vue3 ref”——经常连带被问到的原因。reactive只接受对象内部用new Proxy直接代理ref却能接受原始值靠的是一个名为RefImpl的类把值包在.value里同时对对象类型自动调用reactive转换。源码里RefImpl的简化版本export class RefImplT { private _value: T private _rawValue: T public dep: Dep public readonly __v_isRef true constructor(value: T, public readonly __v_isShallow false) { this._rawValue value this._value toReactive(value) } get value() { trackRefValue(this) return this._value } set value(newVal) { if (hasChanged(newVal, this._rawValue)) { this._rawValue newVal this._value toReactive(newVal) triggerRefValue(this) } } }为什么ref要单独搞一个对象而不是直接返回proxy答案是基本类型没有引用可言如果不加一层对象包裹就没办法在多个地方共享同一个响应式值。const a ref(1)之后你在任意组件里改a.value所有引用它读取的地方都感知得到。reactive则天然只适合对象因为对象本身就是引用传递。在TypeScript类型上ref自动拆包UnwrapRef的设计也是精髓。模板里直接用count不需要写count.value因为模板编译器和类型定义都做了自动拆包处理。这个设计让开发体验和类型安全同时得到兼顾——但如果你直接读源码里的UnwrapRef类型会发现它用条件类型加递归写了好长一串这恰恰是理解TS泛型递归的最佳教材。4.computed的联动更新源码里最精妙的调度链路4.1computed只在需要时才计算lazy effect的核心computed是Vue3里我最推荐的源码阅读模块因为代码量少、逻辑闭环、而且涉及了响应式系统的全部核心概念。先看它的类型签名export function computedT( getter: ComputedGetterT ): ComputedRefT export function computedT( options: WritableComputedOptionsT ): WritableComputedRefT实现上computed内部创建了一个ComputedRefImpl它继承自RefImpl的响应式能力但有两个独特之处一是脏值检查二是延迟更新。用生活化的比喻computed像一个精明的账房先生你问他账目时他才算一遍算完记住结果只有在他记账时用了的那些原始账本发生变化时他才会把记录标记为“需重新计算”但此时还不动手等你真正来问的时候再算。4.2track、trigger、scheduler三者如何组成调度链路看computed源码时最重要的两个字段是_dirty和effect。_dirty标记当前值是否过期effect负责收集依赖。核心代码简化后是export class ComputedRefImplT { public dep?: Dep private _value!: T public readonly __v_isRef true public readonly [ReactiveFlags.IS_READONLY]: boolean public _dirty true public effect: ReactiveEffect constructor(getter, private readonly _setter, isReadonly) { this.effect new ReactiveEffect(getter, () { if (!this._dirty) { this._dirty true triggerRefValue(this) } }) } get value() { trackRefValue(this) if (this._dirty) { this._dirty false this._value this.effect.run() } return this._value } set value(newValue) { this._setter(newValue) } }这里最精妙的是scheduler回调当computed依赖的响应式值变化时并不会立刻设置_dirty false并重新计算而是先设置_dirty true然后主动触发依赖computed的effect。这个设计把“无效计算”省掉了如果多个依赖值在同一轮里变化computed只需标记一次脏值最后一轮统一重算即可。举个例子computed依赖a和b某次操作连续改a、b、a三次。如果是Vue2的纯watcher玩法可能要重复计算多次Vue3靠_dirty标记真正计算只发生一次。这就是为什么Vue3的computed在复杂派生状态场景下比Vue2明显更流畅的核心原因。4.3 面试常问的“computed和watch区别”源码阶段怎么答很多Vue3面试题会让你区分computed和watch。如果你只背“computed是计算属性watch是监听器”那只能拿基础分。从源码层面两者的本质区别是computed内部创建的是一个惰性effect只有读取.value时才执行getterwatch内部创建的是立即或按选项执行的effect不是惰性的。computed暴露的是值供模板或其他状态直接引用有缓存watch暴露的是回调不产生新值只做副作用处理没有缓存概念。computed的更新是“拉取式”的由读取方触发watch的更新是“推送式”的由源变化主动触发。理解这一点后你会发现两者不是可以随便替换的关系模板依赖优先用computed异步操作、DOM操作、状态联动优先用watch。写业务代码时判断逻辑会清晰很多。5. 组件更新与diff优化静态提升、patchFlag、最长递增子序列5.1 Vue2和Vue3 diff的核心差异从双端对比到快速对比diff算法是Vue源码阅读绕不开的硬骨头。Vue2的双端diff四个指针对比已经够让人头疼Vue3在此基础上又做了不少优化。热词里提到的“静态提升、patchFlag、最长递增子序列”就是Vue3优化的三驾马车。先看静态提升。模板里不绑定数据的节点Vue2在每次重新渲染时都会重新创建vnodeVue3在编译阶段把这些节点提升到render函数外部变成常量只创建一次。例如div classcontainer span固定标题/span span{{ dynamicText }}/span /divVue3编译后的render函数大致会变成const _hoisted_1 createElementVNode(div, { class: container }, [ _createElementVNode(span, null, 固定标题, -1 /* HOISTED */) ]) export function render(_ctx, _cache) { return (_openBlock(), createElementBlock(Fragment, null, [ _hoisted_1, createElementVNode(span, null, toDisplayString(_ctx.dynamicText), 1 /* TEXT */) ])) }注意那个-1和1这就是patchFlag编码。静态节点标记为-1表示永远不会变化动态节点标记为1表示只需要比较文本内容。运行时拿到这些标记后可以精准跳过大量无用对比。5.2 patchFlag如何让运行时“开挂”patchFlag不是玄学它就是编译阶段生成的一个数字位图。每个二进制位代表一种更新类型比如flag值含义1动态文本只需要比较text2动态class4动态style8动态props非class/style64稳定片段子节点不需要diff128带key的片段256非响应式节点静态提升运行时patchElement函数拿到新旧vnode后先比较patchFlag再根据flag类型决定走哪段更新逻辑。这样避免了对每个props做全量diff。编译期静态分析 运行期位掩码判断这是Vue3模板整体性能优于Vue2的关键。这里给一个阅读建议打开 Vue3模版编译器在线演示 写几个常见的模板片段对比编译产物。看多了之后你对Vue模板编译的理解会比干读源码深刻得多。5.3 最长递增子序列移动DOM最少的数学解法Vue3 diff里最难啃的是带key列表的diff核心算法是“最长递增子序列Longest Increasing Subsequence”。它的作用是当新旧两个子节点数组对应起来后找出那些在顺序上已经保持相对稳定的节点通过移动其他节点来达到新顺序让移动次数最少。源码里这一段的核心是getSequence函数function getSequence(arr: number[]): number[] { const p arr.slice() const result [0] let i, j, u, v, c const len arr.length for (i 0; i len; i) { const arrI arr[i] if (arrI ! 0) { j result[result.length - 1] if (arr[j] arrI) { p[i] j result.push(i) continue } u 0 v result.length - 1 while (u v) { c (u v) 1 if (arr[result[c]] arrI) { u c 1 } else { v c } } if (arrI arr[result[u]]) { if (u 0) p[i] result[u - 1] result[u] i } } } u result.length v result[u - 1] while (u-- 0) { result[u] v v p[v] } return result }这个函数的输出是一组下标表示“不需要移动的节点在旧列表中的位置”。剩下的节点才需要被移动或新建。阅读时不需要手推每一行重点是搞清楚它为什么用贪心 二分查找贪心保证新加入的节点尽量小让递增序列能容纳更多元素二分查找保证查找插入位置是O(n log n)而不是O(n²)。建议配合可视化diff工具一起看。盯动画几十遍后“最长递增子序列”这个概念就不再是面试题里的纸面名词而是肌肉记忆。6. 源码学习路线图与避坑建议6.1 按什么顺序读源码最省力我的阅读顺序供参考按“从入口到核心从单一到联动”工具层先把vue/shared里常用工具函数过一遍比如isObject、isString、hasChanged。这些都是基础判断不涉及复杂逻辑能快速建立信心。响应式层读vue/reactivity的reactive、ref、computed、effect四个模块。这是最核心、也是最独立的模块不需要依赖其他包。运行时层顺着createApp进入vue/runtime-core对照vnode、component、scheduler逐个攻破。编译器层最后看vue/compiler-core的模板编译流程理解patchFlag是怎么生成的。每一层都建议配一个最小的Vite项目做联调调试。在源码对应的文件里打断点配合console.trace()看调用链比对着代码空想要快得多。6.2 我踩过的几个坑提前帮你排掉第一个坑是直接啃打包后的单文件。打包产物做了大量变量重命名和压缩很多函数名对不上源码直接看dist文件基本等于浪费时间。正确做法是把Vue3仓库clone下来通过别名指向/packages/*/src/index.ts源码入口用Vite启动项目直接解析TS源码。第二个坑是容易被__DEV__条件分支误导。源码里头大量if (__DEV__)包着warning和校验逻辑这些代码在开发模式才执行生产模式会被摇树优化掉。阅读时最好跳过避免被提醒信息干扰主线逻辑。我的习惯是一看到__DEV__、__TEST__之类的标记直接划过去。第三个坑是忘了看vue/shared里的辅助类型。里面有很多类型工具比如UnionToIntersection、LooseRequired等它们被大量引用在组件props、inject等类型推导里。不搞懂这些工具类型很多类型声明会显得像天书。6.3 源码学到的东西如何反向赋能业务开发最后说点实在的。源码学习最直接的好处是你在业务代码里能做出更适合团队的封装。比如你理解了computed的_dirty机制后设计复杂表单的派生状态时会主动避开“实时计算”的写法改用computed惰性求值。你理解patchFlag的意义后写模板时会更自然地用v-once、v-memo做性能优化而不是盲目加key。我个人体会是源码帮我树立了一个标准一个好的前端抽象一定要做到编译期和运行期分工明确。Vue3把静态分析留给编译器把动态更新交给运行时的位掩码判断这套思路直接影响了我在业务里做配置化渲染引擎的设计方式——能编译期确定的就不要留到运行期。啃Vue3源码这件事短期内看起来性价比不高但它是少数能同时打通TypeScript高级技能、框架设计思想、性能优化思路三个维度的学习素材。希望这份路线能帮你绕过那些我走过的弯路把源码读成自己的底层能力。本文还有配套的精品资源点击获取