Vue 3 核心源码解析 - 第一部分：我的架构重生之路

大家好，我是 Vue 3.0！今天我想和大家聊聊我的"重生"故事。从 Vue 2 到 Vue 3，这不仅仅是版本号的跳跃，更是我整个架构的华丽转身。让我带你走进我的内心世界，看看我是如何从一个"单体应用"进化成"微服务架构"的。

🎭 序章：一个框架的自白

2020年9月18日，那是一个值得纪念的日子。经过两年多的重构，我终于以全新的面貌与大家见面了。如果说 Vue 2 的我像是一个刚毕业的大学生，那么 Vue 3 的我就是一个经验丰富的架构师。

这次重构，我学会了很多新技能：

• 🏗️ Monorepo 架构：告别了单一仓库的混乱，拥抱了模块化的清晰
• 🔧 TypeScript 原生支持：从 Flow 转向 TypeScript，类型安全我拿捏了
• ⚡ Tree-shaking 友好：按需加载，性能优化我是认真的
• 🎯 Composition API：函数式编程，让逻辑复用更优雅

但今天，我想先从我的"骨架"说起------我的项目架构。

🏛️ 第一章：从混沌到秩序的 Monorepo 革命

回忆杀：Vue 2 时代的"单打独斗"

还记得 Vue 2 时代的我吗？那时候我就是一个大大的 vue 包，所有功能都塞在一起：

vue/
├── src/
│   ├── core/          # 核心功能
│   ├── platforms/     # 平台相关
│   ├── compiler/      # 编译器
│   ├── server/        # 服务端渲染
│   └── ...
└── dist/              # 构建产物

虽然看起来简单，但问题也很明显：

• 🤯 耦合度高：想要单独使用响应式系统？不好意思，得把整个我都带上
• 📦 包体积大：即使你只用了我的一小部分功能，也得下载完整的包
• 🔧 维护困难：一个小改动可能影响到整个系统

觉醒：拥抱 Monorepo 的新时代

到了 Vue 3，我决定来一次彻底的"解构重组"。我把自己拆分成了多个独立的包，每个包都有自己的职责：

packages/
├── vue/                    # 主包，整合所有功能
├── reactivity/            # 响应式系统
├── runtime-core/          # 平台无关的运行时
├── runtime-dom/           # DOM 相关的运行时
├── compiler-core/         # 平台无关的编译器
├── compiler-dom/          # DOM 相关的编译器
├── compiler-sfc/          # 单文件组件编译器
├── server-renderer/       # 服务端渲染
├── shared/               # 共享工具函数
└── vue-compat/           # Vue 2 兼容层

这样的设计有什么好处呢？让我用一个比喻来解释：

想象一下，Vue 2 的我就像是一个"全能型选手"，什么都会但什么都不够专精。而 Vue 3 的我就像是一个"专业团队"，每个成员都有自己的专长，但又能完美配合。

深入解析：每个包的"人设"

让我来介绍一下我的这些"分身"们：

🎯 @vue/reactivity - 响应式系统专家

这是我最引以为豪的核心能力。在 Vue 3 中，我把响应式系统完全独立出来了：

// 可以完全脱离 Vue 使用
import { ref, computed, effect } from '@vue/reactivity'

const count = ref(0)
const doubled = computed(() => count.value * 2)

effect(() => {
  console.log(`Count is: ${count.value}`)
})

count.value++ // 自动触发 effect

这个包的独立性让我可以在任何地方使用响应式能力，甚至在 React 项目中！（虽然这样做有点叛逆 😏）

🏃‍♂️ @vue/runtime-core - 运行时核心

这是我的"大脑"，包含了组件系统、虚拟 DOM、调度器等核心逻辑，但不包含任何平台特定的代码：

// 平台无关的组件定义
import { createRenderer } from '@vue/runtime-core'

// 可以为任何平台创建渲染器
const { render, createApp } = createRenderer({
  patchProp,
  insert,
  remove,
  createElement,
  // ... 平台特定的操作
})

🌐 @vue/runtime-dom - DOM 操作专家

这是我在浏览器环境的"手脚"，专门处理 DOM 相关的操作：

// DOM 特定的渲染器
import { createApp } from '@vue/runtime-dom'

const app = createApp({
  template: '<div>Hello Vue 3!</div>'
})
app.mount('#app')

🔧 编译器三兄弟

• @vue/compiler-core：编译器核心，平台无关
• @vue/compiler-dom：DOM 相关的编译逻辑
• @vue/compiler-sfc：单文件组件编译器

这三个包的分工让我可以为不同平台提供定制化的编译能力。

🛠️ 第二章：共享工具箱的智慧 - @vue/shared 深度解析

在我的架构中，有一个特别的存在------@vue/shared。它就像是我的"工具箱"，存放着各个包都需要用到的工具函数。

为什么需要 shared？

想象一下，如果每个包都要实现自己的工具函数，会发生什么？

// 如果没有 shared，可能会这样：
// packages/reactivity/src/utils.ts
const isObject = (val) => val !== null && typeof val === 'object'

// packages/runtime-core/src/utils.ts  
const isObject = (val) => val !== null && typeof val === 'object' // 重复了！

// packages/compiler-core/src/utils.ts
const isObject = (val) => val !== null && typeof val === 'object' // 又重复了！

这样不仅代码重复，还增加了维护成本。所以我创建了 @vue/shared，把所有通用的工具函数都放在这里。

shared 包的核心工具函数

让我们看看这个工具箱里都有什么宝贝：

🔍 类型判断工具

// packages/shared/src/index.ts

// 基础类型判断
export const isString = (val: unknown): val is string => typeof val === 'string'
export const isNumber = (val: unknown): val is number => typeof val === 'number'
export const isObject = (val: unknown): val is Record<any, any> =>
  val !== null && typeof val === 'object'

// 特殊类型判断
export const isArray = Array.isArray
export const isFunction = (val: unknown): val is Function =>
  typeof val === 'function'
export const isPromise = <T = any>(val: unknown): val is Promise<T> => {
  return isObject(val) && isFunction(val.then) && isFunction(val.catch)
}

这些函数看起来简单，但在我的各个包中使用频率极高。统一管理让我的代码更加一致和可靠。

🎯 对象操作工具

// 空对象常量，避免重复创建
export const EMPTY_OBJ: { readonly [key: string]: any } = {}
export const EMPTY_ARR = []

// 对象属性检查
export const hasOwn = (
  val: object,
  key: string | symbol
): key is keyof typeof val => Object.prototype.hasOwnProperty.call(val, key)

// 对象扩展
export const extend = Object.assign

// 移除数组元素
export const remove = <T>(arr: T[], el: T) => {
  const i = arr.indexOf(el)
  if (i > -1) {
    arr.splice(i, 1)
  }
}

🚀 性能优化工具

// 创建映射对象，用于快速查找
export const makeMap = (
  str: string,
  expectsLowerCase?: boolean
): ((key: string) => boolean) => {
  const map: Record<string, boolean> = Object.create(null)
  const list: Array<string> = str.split(',')
  for (let i = 0; i < list.length; i++) {
    map[list[i]] = true
  }
  return expectsLowerCase ? val => !!map[val.toLowerCase()] : val => !!map[val]
}

// HTML 标签检查
export const isHTMLTag = makeMap(
  'html,body,base,head,link,meta,style,title,' +
  'address,article,aside,footer,header,h1,h2,h3,h4,h5,h6,nav,section,' +
  // ... 更多标签
)

这个 makeMap 函数特别有意思，它通过预计算创建一个哈希表，让标签检查的时间复杂度从 O(n) 降到 O(1)。

🎨 字符串处理工具

// 缓存函数，避免重复计算
const cacheStringFunction = <T extends (str: string) => string>(fn: T): T => {
  const cache: Record<string, string> = Object.create(null)
  return ((str: string) => {
    const hit = cache[str]
    return hit || (cache[str] = fn(str))
  }) as T
}

// 驼峰命名转换
export const camelize = cacheStringFunction((str: string): string => {
  return str.replace(/-(\w)/g, (_, c) => (c ? c.toUpperCase() : ''))
})

// 首字母大写
export const capitalize = cacheStringFunction(
  (str: string) => str.charAt(0).toUpperCase() + str.slice(1)
)

// 连字符命名转换
export const hyphenate = cacheStringFunction((str: string) =>
  str.replace(/\B([A-Z])/g, '-$1').toLowerCase()
)

注意这里的 cacheStringFunction，这是一个高阶函数，用来缓存字符串转换的结果。在模板编译过程中，同样的属性名可能会被转换多次，缓存可以显著提升性能。

shared 包的设计哲学

@vue/shared 的设计体现了我的几个核心理念：

1. DRY 原则：Don't Repeat Yourself，避免代码重复
2. 性能优先：每个工具函数都经过性能优化
3. 类型安全：充分利用 TypeScript 的类型系统
4. 最小化依赖：不依赖任何外部库，保持纯净

🏗️ 第三章：构建系统的进化之路

从 Webpack 到 Rollup 的选择

在 Vue 2 时代，我使用的是 Webpack 作为构建工具。但在 Vue 3 中，我选择了 Rollup。为什么呢？

Webpack 的优势：

• 🔥 热更新支持好
• 📦 代码分割能力强
• 🔌 插件生态丰富

Rollup 的优势：

• 🌳 Tree-shaking 更彻底
• 📦 打包体积更小
• 🎯 更适合库的构建

作为一个框架，我更关心最终产物的质量，所以选择了 Rollup。

构建配置的艺术

让我们看看我的构建配置是如何设计的：

// rollup.config.js (简化版)
const configs = []

// 为每个包创建构建配置
if (process.env.TARGET) {
  // 构建单个包
  configs.push(createConfig(process.env.TARGET))
} else {
  // 构建所有包
  targets.forEach(target => {
    configs.push(createConfig(target))
  })
}

function createConfig(target) {
  const pkg = require(`./packages/${target}/package.json`)
  const options = pkg.buildOptions || {}
  
  return {
    input: `packages/${target}/src/index.ts`,
    output: createOutput(target, options),
    plugins: createPlugins(target, options),
    external: createExternal(target)
  }
}

多格式输出策略

我支持多种输出格式，以适应不同的使用场景：

// 不同的输出格式
const formats = {
  'esm-bundler': {
    // 给打包工具使用的 ES 模块
    format: 'es',
    ext: 'esm-bundler.js'
  },
  'esm-browser': {
    // 给浏览器直接使用的 ES 模块
    format: 'es',
    ext: 'esm-browser.js'
  },
  'cjs': {
    // CommonJS 格式
    format: 'cjs',
    ext: 'cjs.js'
  },
  'global': {
    // 全局变量格式
    format: 'iife',
    ext: 'global.js'
  }
}

每种格式都有其特定的用途：

• esm-bundler：给 Vite、Webpack 等打包工具使用
• esm-browser：给现代浏览器直接使用
• cjs：给 Node.js 环境使用
• global ：通过 <script> 标签直接引入

开发环境的贴心设计

在开发环境中，我提供了很多贴心的功能：

// 开发环境特有的功能
if (__DEV__) {
  // 详细的警告信息
  warn(`Invalid prop: type check failed for prop "${name}".`)
  
  // 组件名称推断
  if (!Component.name) {
    Component.name = inferComponentName(Component)
  }
  
  // 性能追踪
  if (__FEATURE_PROD_DEVTOOLS__) {
    devtools.emit('component:updated', instance)
  }
}

这些代码在生产环境中会被完全移除，既保证了开发体验，又不影响生产性能。

🎯 第四章：TypeScript 的全面拥抱

从 Flow 到 TypeScript 的转变

Vue 2 时代，我使用的是 Flow 作为类型检查工具。但在 Vue 3 中，我完全转向了 TypeScript。这个决定不是一时冲动，而是经过深思熟虑的：

为什么选择 TypeScript？

1. 生态更好：TypeScript 的生态系统更加繁荣
2. 工具支持：IDE 支持更完善
3. 社区接受度：开发者更熟悉 TypeScript
4. 类型推断：TypeScript 的类型推断能力更强

TypeScript 在架构中的应用

在我的架构中，TypeScript 不仅仅是类型检查工具，更是设计工具：

// 通过类型约束 API 设计
export interface ComponentOptions<T = any> {
  data?: () => T
  computed?: Record<string, ComputedGetter<any> | WritableComputedOptions<any>>
  methods?: Record<string, Function>
  // ...
}

// 通过泛型提供类型安全
export function defineComponent<Props, RawBindings = object>(
  setup: (props: Props, ctx: SetupContext) => RawBindings
): ComponentPublicInstanceConstructor<Props & RawBindings>

类型体操的艺术

在 Vue 3 中，我大量使用了 TypeScript 的高级类型特性：

// 递归解包 Ref 类型
export type UnwrapRef<T> = T extends Ref<infer V>
  ? UnwrapRefSimple<V>
  : UnwrapRefSimple<T>

// 条件类型的巧妙应用
export type ComputedRef<T> = {
  readonly value: T
  readonly [RefSymbol]: true
}

// 映射类型的使用
export type ComponentPropsOptions<P = Data> = {
  [K in keyof P]: Prop<P[K]> | null
}

这些类型定义看起来复杂，但它们为开发者提供了完美的类型推断和检查。

🌟 第五章：设计模式的运用

单一职责原则

我的每个包都遵循单一职责原则：

• @vue/reactivity：只负责响应式
• @vue/runtime-core：只负责运行时核心逻辑
• @vue/compiler-core：只负责编译核心逻辑

这样的设计让每个包都可以独立发展，互不干扰。

依赖倒置原则

在我的架构中，高层模块不依赖低层模块，都依赖抽象：

// runtime-core 定义抽象接口
export interface RendererOptions<HostNode, HostElement> {
  patchProp(el: HostElement, key: string, prevValue: any, nextValue: any): void
  insert(el: HostNode, parent: HostElement, anchor?: HostNode | null): void
  remove(el: HostNode): void
  createElement(type: string): HostElement
}

// runtime-dom 实现具体逻辑
const rendererOptions: RendererOptions<Node, Element> = {
  patchProp: patchDOMProp,
  insert: (child, parent, anchor) => {
    parent.insertBefore(child, anchor || null)
  },
  // ...
}

工厂模式

我大量使用工厂模式来创建不同的实例：

// 创建渲染器的工厂函数
export function createRenderer<HostNode, HostElement>(
  options: RendererOptions<HostNode, HostElement>
) {
  return baseCreateRenderer(options)
}

// 创建应用的工厂函数
export function createApp(rootComponent: Component, rootProps?: any) {
  const app = createAppAPI(render)(rootComponent, rootProps)
  return app
}

🚀 第六章：性能优化的智慧

Tree-shaking 友好的设计

我的架构天然支持 Tree-shaking：

// 每个功能都是独立导出的
export { ref, reactive, computed } from '@vue/reactivity'
export { createApp, defineComponent } from '@vue/runtime-dom'

// 使用时可以按需导入
import { ref, computed } from 'vue'
// 只有 ref 和 computed 相关的代码会被打包

代码分割策略

我支持多种代码分割策略：

// 运行时 + 编译器
import { createApp } from 'vue'

// 仅运行时（体积更小）
import { createApp } from 'vue/dist/vue.runtime.esm-bundler.js'

// 按需加载编译器
const { compile } = await import('@vue/compiler-dom')

构建时优化

在构建过程中，我会进行各种优化：

// 移除开发环境代码
if (__DEV__) {
  // 这些代码在生产环境会被移除
}

// 特性标记
if (__FEATURE_OPTIONS_API__) {
  // 如果不需要 Options API，这些代码会被移除
}

🎭 尾声：架构设计的哲学思考

回顾我的架构重构之路，我想分享几个核心的设计哲学：

1. 模块化思维

"大系统是由小系统组成的，小系统的质量决定了大系统的质量。"

我把自己拆分成多个小而美的包，每个包都有清晰的边界和职责。这不仅让我更容易维护，也让开发者可以按需使用。

2. 渐进式增强

"不要一开始就给用户最复杂的东西，让他们可以渐进式地学习和使用。"

我的架构支持从简单到复杂的渐进式使用：

• 可以只使用响应式系统
• 可以只使用运行时
• 也可以使用完整功能

3. 性能优先

"性能不是优化出来的，而是设计出来的。"

从架构设计开始，我就考虑了性能问题：

• Tree-shaking 友好的模块设计
• 编译时优化
• 运行时性能监控

4. 开发体验

"好的工具应该让开发者感觉不到它的存在。"

我的架构设计始终考虑开发体验：

• 完善的 TypeScript 支持
• 清晰的错误信息
• 丰富的开发工具

📚 下期预告

在下一篇文章中，我将深入讲解我的核心能力------响应式系统。我会告诉你：

• 我是如何实现比 Vue 2 更高效的响应式系统的
• Proxy 相比 Object.defineProperty 的优势在哪里
• 我的依赖收集和触发机制是如何工作的
• 如何处理复杂的嵌套对象和数组

敬请期待！

---

💡 小贴士 ：如果你想深入了解我的源码，建议从 packages/shared 开始，然后是 packages/reactivity，最后是 packages/runtime-core。这样的顺序可以让你更好地理解我的设计思路。
🎯 实践建议：试着创建一个简单的 monorepo 项目，体验一下模块化架构的优势。你可以参考我的项目结构，创建自己的工具库。

---