Vue 3.6 深度解析：Vapor Mode 与 alien-signals 如何从底层重写前端性能范式

前言

2026年7月，前端框架江湖又起波澜。Vue 3.6 带着两个极具分量的新特性——Vapor Mode 和 alien-signals——正式进入 Beta 阶段。虽然这还不是正式发布，但 Beta.17（2026-06-24）的表现已经足够震撼：Vapor Mode 可以在 100ms 内完成 10 万个组件的挂载，alien-signals 让 computed 的吞吐量比 Vue 3.5 快了 30 倍以上。

这两个数字不是小打小闹的优化，而是量级层面的跃迁。当你把这两项技术合在一起看，会发现 Vue 正在做一件它历史上从未做过的事：从根本上重构自己的执行引擎。

这篇文章，我会从为什么需要 Vapor Mode开始，深入到它的编译原理；然后解析 alien-signals 这个 1KB 的极简响应式库如何实现 30 倍性能提升；最后聊聊这两个变化对整个前端生态意味着什么。全程配有可运行的代码示例，确保你读完就能动手实践。

一、为什么虚拟 DOM 成了"性能债"

1.1 虚拟 DOM 的历史功绩

2013 年，React 引入虚拟 DOM（Virtual DOM，简称 VDOM），彻底改变了前端渲染的思路。它不再直接操作真实 DOM，而是先在内存中构建一棵虚拟节点树（VNode Tree），通过 diff 算法比较新旧两棵树的差异，再精准更新真实 DOM。

这个思路在当时极其高明：

• 跨平台能力：同一套 VNode 树可以渲染到 DOM、Server、Native 等多个目标
• 批量更新：React 的 reconciler 可以合并多次状态变更，一次性应用
• 开发体验：声明式 UI 让开发者不用关心"怎么改"，只关心"变成什么样"

Vue 2.0（2016年）采纳了这一方案，并在此基础上做了大量优化，比如使用了更高效的 diff 算法（Snabbdom 风格）。Vue 3 的 Proxy-based 响应式系统更是业界标杆，配合 VDOM，让 Vue 成为过去十年最受欢迎的前端框架之一。

1.2 当复杂度超过临界点

但"够用"和"最优"从来不是一回事。虚拟 DOM 的代价，在大规模应用中开始变得无法忽视：

VNode 分配开销：每次组件渲染，都要实例化大量 VNode 对象。这些对象是堆分配的，会给 GC 造成持续压力。在高频更新场景下，GC 停顿会导致可感知的卡顿。

diff 算法的不可避免性：即使 Vue 3 的 patchFlag 优化已经非常出色，diff 算法本身仍然需要遍历整棵树。组件数量越多，diff 的成本越高。

运行时的必然存在：VDOM 的运行时代码必须打包进最终产物。无论你的业务逻辑多么简单，运行时开销始终在那里。

以一个真实场景为例：假设你的应用有 5,000 个表格行，每行 20 个单元格。当用户点击排序时，5,000 × 20 = 100,000 个 VNode 需要重新创建和 diff。这还没算后续的 patch 操作。

这就是为什么 Svelte 和 SolidJS 选择完全放弃 VDOM，通过编译时分析直接生成 DOM 操作代码。它们的思路是：既然模板是静态可分析的，那为什么要在运行时做 diff？

Vue 3.6 终于给出了自己的答案：Vapor Mode。

二、Vapor Mode：从 VDOM 到零运行时

2.1 核心编译策略

Vapor Mode 是 Vue SFC（Single File Component）的一种全新编译策略。它不是在 Vue 运行时实现的，而是在编译时完成的。

传统 Vue 组件的编译产物（以 render 函数为例）：

// 传统 Vue 3 SFC 编译产物（简化版）
import { createElementVNode as _createElementVNode, createTextVNode as _createTextVNode, vnodeArgs } from 'vue'

export function render(_ctx, _cache) {
  return (_openBlock(), _createElementBlock('button', {
    onClick: _cache[0] || (_cache[0] = $event => (_ctx.count++))
  }, "Clicked " + _toDisplayString(_ctx.count) + " times", 1 /* TEXT */))
}

可以看到，这里生成的是 createElementBlock 和 createElementVNode——这些是 VDOM 运行时的一部分。

Vapor Mode 编译产物：

// Vapor Mode 编译产物（直接操作真实 DOM）
import { createVaporSignal, vaporUpdate, vaporMount } from '@vue/runtime-vapor'

const [count, setCount] = createVaporSignal(0)
const _el = document.createElement('button')
_el.addEventListener('click', () => setCount(count() + 1))

vaporMount(_el, () => {
  _el.textContent = `Clicked ${count()} times`
})

关键区别：没有 VNode，没有 createElementBlock，没有 diff，只有直接操作真实 DOM 的代码。

2.2 启用方式：极其简单

Vapor Mode 的设计哲学是渐进式采用。你不需要重写整个应用，只需要在想优化的组件上做一点小改动。

方式一：<script vapor> 标签

<script vapor>
import { ref } from 'vue'

const count = ref(0)
const message = ref('Hello')

function increment() {
  count.value++
}
</script>

<template>
  <div class="counter">
    <h1>{{ message }} {{ count }}</h1>
    <button @click="increment">点击</button>
  </div>
</template>

这就是全部改动——把 <script> 改成 <script vapor>，编译器就会生成 Vapor 模式代码。

方式二：文件名约定

不想改源码？可以。把文件名从 Counter.vue 改成 Counter.vapor.vue，编译器会自动应用 Vapor Mode。

# 普通组件
src/components/Counter.vue

# Vapor 组件（文件名约定）
src/components/Counter.vapor.vue

方式三：创建纯 Vapor 应用

如果你是全新项目，可以使用 createVaporApp() 创建完全不包含 VDOM 运行时的应用：

// main.ts
import { createVaporApp } from 'vue'
import App from './App.vapor.vue'

// 最终打包产物中不包含任何 VDOM 相关代码
createVaporApp(App).mount('#app')

这个打包产物的体积可以比传统 Vue 应用小 60% 以上（具体取决于组件数量和复杂程度）。

2.3 在现有应用中混合使用

Vapor Mode 支持和传统 VDOM 组件混合使用。Vue 提供了 vaporInteropPlugin：

import { createApp } from 'vue'
import { vaporInteropPlugin } from '@vue/runtime-vapor'
import App from './App.vue'
import Counter from './Counter.vapor.vue'

const app = createApp(App)

// 注册 Vapor 互操作插件
app.use(vaporInteropPlugin)

// 注册 Vapor 组件（会自动处理跨模式通信）
app.component('Counter', Counter)

app.mount('#app')

这种混合模式下，Vapor 组件和 VDOM 组件可以互相嵌套。Vue 的互操作层会处理边界情况，比如 props 传递、事件冒泡等。

2.4 性能数据：不只是"快一点"

根据 Vue 官方在 Beta 发布说明中公布的数据，以及 js-framework-benchmark 的测试结果：

"100ms 挂载 10 万组件"是什么概念？SolidJS 约为 80-90ms，Svelte 5 约为 100-110ms。Vue 的 Vapor Mode 已经和这两个以"极致性能"著称的框架站在了同一梯队。

2.5 当前限制与注意事项

Vapor Mode 目前处于 Beta 阶段，有一些限制需要了解：

无法使用的特性：

• ❌ Options API（仅支持 Composition API）
• ❌ getCurrentInstance() 和 app.config.globalProperties
• ❌ Suspense（但可以在 VDOM Suspense 中渲染 Vapor 组件）
• ❌ renderSlot() / slots.default() 跨模式边界问题

需要关注的兼容性：

• SSR hydration 已支持（Nuxt 适配中）
• 第三方组件库需要逐步迁移，高频渲染组件可以优先尝试
• 生产环境建议等待正式版（正式版预计在 2026 Q4）

实战建议：不要急于大规模迁移。先在以下场景尝试：

1. 性能瓶颈页面中的列表/表格组件
2. 数据看板的图表组件（高频重渲染）
3. 全新项目且对性能敏感的场景

三、alien-signals：1KB 如何实现 30 倍性能

3.1 一个 1KB 的故事

如果说 Vapor Mode 解决的是"渲染层"的问题，那么 alien-signals 解决的是"响应式层"的问题——而且是从根本上重新设计。

alien-signals 的诞生颇具传奇色彩。Vue 核心贡献者 Johnson Chu 在研究 Vue 响应式系统进一步优化时，发现 Vue 3.5 的 Pull-based 算法仍有提升空间。他决定将研究方向独立出来，探索 Push-Pull 混合算法的可能性，这就是 alien-signals 的起源。

这个库的最终产物压缩后只有 1KB。但就是这 1KB，因为性能太过出色，被直接移植回了 Vue 3.6 的核心代码库。

原始 alien-signals 库体积：~5KB（未压缩）
Gzip 压缩后：~1KB
最终移植到 Vue 核心的代码量：~12KB（含 TypeScript 类型）

3.2 为什么响应式系统会变慢

要理解 alien-signals 的价值，需要先理解 Vue 3.5 响应式系统的瓶颈在哪里。

Vue 3 的响应式系统基于 Proxy。核心流程是：

// Vue 3.5 的响应式追踪（简化版）
const obj = reactive({ count: 0 })

// 当 effect 访问 obj.count 时：
// 1. Proxy get trap 触发
// 2. 将当前 activeEffect 记录到 count 的 dep 集合
// 3. 返回 count 的值

effect(() => {
  console.log(obj.count) // 触发依赖追踪
})

Vue 3.5 的问题是：它采用了类似 Preact 的纯 Pull-based 算法。这意味着：

• signal 变化时，什么都不会立即发生
• 只有在读取 computed 或 effect 访问时，才会检查依赖是否过期
• 在高频读取场景下，每次读取都要遍历 dep 集合检查 dirty 标志

当你的应用有 100,000 个 computed，每次都需要遍历检查，性能损耗就非常可观了。

3.3 Push-Pull 混合算法

alien-signals 的核心创新是Push-Pull 混合调度算法：

Push 阶段（dirty 标记传播）：

signal.value = newValue
→ 标记当前 signal 为 dirty
→ 立即通知所有下游 computed/effect：你们的依赖已过期
→ 不执行任何实际计算！

Pull 阶段（惰性重算）：

computed() 被访问
→ 检查 dirty 标志
→ dirty = true → 执行求值函数
→ 更新缓存值
→ 返回新值

// alien-signals 核心实现思路（简化版）
import { signal, computed, effect } from 'alien-signals'

// 创建响应式数据
const count = signal(1)
const multiplier = signal(2)

// 派生计算（惰性求值）
const product = computed(() => count() * multiplier())

// 副作用（自动追踪依赖）
effect(() => {
  console.log(`Product: ${product()}`)
})
// 立即输出: Product: 2

count(5)
// Push 阶段：标记 product 为 dirty
// Pull 阶段：访问 product() 时重算
// 输出: Product: 10

这种设计的关键洞察：Push 阶段只需要传播"脏了"这个布尔标志，不需要执行任何实际计算。 实际的计算只在 Pull 阶段、由真正需要结果的地方触发。

3.4 双向链表依赖追踪

alien-signals 选择了双向链表而非 Set/Map 来管理依赖关系，这是另一个性能关键点。

传统的 Set/Map 方案：

• 每次添加/删除依赖需要哈希计算
• 内存占用较大（Set 的节点比链表节点更复杂）

双向链表方案：

// 简化版双向链表节点
class SubscriberNode {
  constructor(fn, prev, next) {
    this.fn = fn
    this.prev = prev
    this.next = next
    if (prev) prev.next = this
    if (next) next.prev = this
  }
  // O(1) 添加兄弟节点
  addSibling(sibling) { /* ... */ }
  // O(1) 移除自身
  remove() { /* ... */ }
}

• O(1) 时间复杂度的插入和删除
• 内存占用更紧凑（比 Set 更小的节点结构）
• 更符合 CPU 缓存局部性（节点在内存中连续排列）

配合版本标记（globalVersion）脏检查机制，可以快速判断依赖是否真的需要重算：

// 版本标记机制
let globalVersion = 0

function signal(value) {
  let currentVersion = 0
  let currentValue = value
  
  return function get(newValue) {
    if (arguments.length === 0) {
      // 读取：检查是否脏了
      return currentVersion === globalVersion ? currentValue : recompute()
    } else {
      // 写入：更新值并递增版本
      currentValue = newValue
      currentVersion = ++globalVersion
      notifySubscribers()
    }
  }
}

3.5 设计约束：刻意为之的极简主义

alien-signals 在实现上施加了几个刻意为之的工程约束，这些约束是它性能出色的根源：

约束一：核心数据结构不使用 Array/Set/Map

// ❌ 不用这些
const deps = new Set()
const depMap = new Map()

// ✅ 用链表
class LinkedList { head; tail; }

约束二：禁止函数递归

// ❌ 不允许
function traverse(node) {
  if (node.children) {
    node.children.forEach(traverse) // 递归可能导致栈溢出
  }
}

// ✅ 改用迭代
function traverse(root) {
  const stack = [root]
  while (stack.length) {
    const node = stack.pop()
    // 处理 node
    if (node.children) stack.push(...node.children)
  }
}

约束三：位运算状态标志

// ❌ 不用独立布尔字段
let isDirty = true
let isPaused = false
let isDisposed = false

// ✅ 用位标志
const DIRTY = 1 << 0  // 1
const PAUSED = 1 << 1 // 2
const DISPOSED = 1 << 2 // 4
let state = DIRTY | PAUSED // 3：同时是 dirty 和 paused

约束四：类属性 < 10 个
这确保了对象符合 V8 引擎的"快速属性访问"优化条件，减少了隐藏类（Hidden Class）切换的开销。

3.6 性能对比数据

来自 vue-performance-compare 基准测试（200,000 refs、100,000 computed、20,000 effects）：

Vue 官方在 Beta 发布说明中给出的数据更激进：响应式性能比 Vue 3.5 快约 1.8 倍，computed 吞吐量高出 30 倍以上，内存占用降低 65%。

30 倍的 computed 吞吐量提升，在什么场景下有意义？比如一个数据仪表盘应用，有 100+ 个 computed 分别计算不同 KPI，当底层数据源更新时，这 100+ 个 computed 需要重新计算。在 Vue 3.5 中这可能需要 50ms，在 Vue 3.6 中只需要不到 2ms——用户根本感受不到数据更新带来的任何延迟。

四、双引擎合璧：Vue 的"换芯手术"

4.1 两套引擎的协同工作

Vapor Mode 和 alien-signals 解决的是不同层面的问题，但它们可以协同工作：

<!-- performance-critical.vapor.vue -->
<script vapor>
import { ref, computed } from 'vue'

// 这里用 alien-signals 引擎（响应式层）
const data = ref([])

// 派生计算完全由 alien-signals 驱动
const average = computed(() => {
  if (!data.value.length) return 0
  return data.value.reduce((a, b) => a + b, 0) / data.value.length
})

// 模拟数据加载
async function loadData() {
  const res = await fetch('/api/metrics')
  data.value = await res.json()
}
</script>

<template>
  <div>
    <h2>平均值: {{ average }}</h2>
    <ul>
      <li v-for="item in data" :key="item.id">
        {{ item.name }}: {{ item.value }}
      </li>
    </ul>
  </div>
</template>

在 Vapor Mode 组件中，alien-signals 是默认的响应式引擎。这意味着：

• 响应式层（信号追踪、依赖收集）：alien-signals（Push-Pull 混合）
• 渲染层（DOM 操作）：编译器生成直接操作代码（无 VDOM）

4.2 打包产物的变化

让我们看一个具体的打包产物对比。假设有一个简单的 Todo 列表组件（包含 3 个 ref，2 个 computed，1 个 effect）：

传统打包产物：

dist/
  index.html
  assets/
    index-[hash].js    ~250KB（包含 VDOM 运行时）
    index-[hash].css  ~15KB

Vapor Mode 打包产物：

dist/
  index.html
  assets/
    index-[hash].js    ~95KB（不含 VDOM 运行时）
    index-[hash].css  ~15KB

节省了约 60% 的 JS 体积。在移动端或者弱网环境下，这 155KB 的差距就是"能打开"和"等三秒"的区别。

五、对 Vue 生态的深层影响

5.1 Nuxt 的下一步

Nuxt 4 正在积极适配 Vue 3.6 的新特性。当 Vapor Mode 的 SSR hydration 完全稳定后：

// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    vaporMode: true  // 启用 Vapor Mode
  }
})

服务端渲染 + 编译时优化的组合，将让 Nuxt 应用的 TTFB（Time To First Byte）和 FCP（First Contentful Paint）有显著提升。

5.2 组件库的进化路径

现有 Vue 组件库（Element Plus、Vuetify、Ant Design Vue 等）不需要从零重写，可以采取渐进式迁移：

// 迁移策略：按组件粒度选择模式
// 高频渲染组件 → Vapor Mode
// 复杂交互组件 → 保持 VDOM

// 例如：表格行组件迁移为 Vapor
export default defineComponent({
  name: 'TableRow',
  // 性能关键，使用 Vapor
  vapor: true,  // 即将支持的语法
  props: {
    row: Object,
    selected: Boolean
  },
  setup(props) {
    const style = computed(() => ({
      background: props.selected ? '#f5f7fa' : '#fff'
    }))
    return { style }
  }
})

5.3 Pinia 的新底座

Pinia 3 正在考虑将底层响应式追踪切换为 alien-signals 兼容实现。由于 alien-signals 的 API（signal/computed/effect）与 Pinia 的 store 设计高度契合，这个迁移对用户来说基本透明：

// 现有代码无需改动（Pinia 3 会自动使用新引擎）
const useCounterStore = defineStore('counter', () => {
  const count = ref(0)
  const doubled = computed(() => count.value * 2)
  
  function increment() {
    count.value++
  }
  
  return { count, doubled, increment }
})

六、与其他框架的横向对比

6.1 性能横向对比（js-framework-benchmark）

Vue 3.6 Vapor Mode 已经和 SolidJS、Svelte 5 处于同一性能梯队，彻底告别了"Vue 性能不如编译型框架"的偏见。

6.2 迁移成本对比

Vue 的优势在于：渐进式采用。你可以把 Vue 3.6 的 Vapor Mode 当作一个额外的优化工具，而不必把它当作一次范式转换。

七、实战：从零构建一个 Vapor Mode 组件

7.1 环境准备

# 使用 Vite 创建 Vue 项目
npm create vite@latest my-vapor-app -- --template vue-ts
cd my-vapor-app

# 安装 Vue 3.6 beta（指定版本号）
npm install vue@3.6.0-beta.17

# 确认版本
npm list vue
# vue@3.6.0-beta.17

7.2 基础计数器组件

<!-- src/components/VaporCounter.vue -->
<script vapor>
import { ref, computed } from 'vue'

// ref → alien-signals 驱动的响应式容器
const count = ref(0)
const step = ref(2)
const history = ref<number[]>([])

// computed → 惰性派生值（alien-signals Push-Pull 驱动）
const squared = computed(() => count.value * count.value)
const doubled = computed(() => count.value * step.value)

// 方法
function increment() {
  history.value.push(count.value)
  count.value += step.value
}

function decrement() {
  history.value.push(count.value)
  count.value -= step.value
}

function reset() {
  count.value = 0
  history.value = []
}

// 导出给模板使用
return { count, step, history, squared, doubled, increment, decrement, reset }
</script>

<template>
  <div class="counter">
    <h1>{{ count }}</h1>
    <p>平方: {{ squared }} | 双倍: {{ doubled }}</p>
    
    <div class="controls">
      <button @click="decrement">-</button>
      <button @click="reset">重置</button>
      <button @click="increment">+</button>
    </div>
    
    <div class="step-control">
      <label>步长:</label>
      <input type="number" v-model.number="step" />
    </div>
    
    <details v-if="history.length">
      <summary>历史 ({{ history.length }} 条)</summary>
      <ul>
        <li v-for="(val, i) in history.slice(-5)" :key="i">{{ val }}</li>
      </ul>
    </details>
  </div>
</template>

<style scoped>
.counter {
  font-family: system-ui, sans-serif;
  max-width: 400px;
  margin: 2rem auto;
  text-align: center;
}
.controls button {
  margin: 0 0.5rem;
  padding: 0.5rem 1rem;
  font-size: 1.2rem;
  cursor: pointer;
}
.step-control {
  margin-top: 1rem;
}
.history {
  margin-top: 1rem;
  text-align: left;
}
</style>

7.3 在应用中混合使用

<!-- src/App.vue -->
<script setup>
import VaporCounter from './components/VaporCounter.vue'
import VDOMList from './components/VDOMList.vue'
import { ref } from 'vue'

const appTitle = ref('我的 Vue 3.6 应用')
</script>

<template>
  <main>
    <h1>{{ appTitle }}</h1>
    <!-- Vapor 组件 -->
    <VaporCounter />
    <hr />
    <!-- VDOM 组件 -->
    <VDOMList />
  </main>
</template>

7.4 性能验证

在你的应用中打开 Vue DevTools，找到"性能"面板，启用"组件性能记录"。你会发现 Vapor Mode 组件的渲染时间和内存占用明显低于 VDOM 组件。

也可以直接观察 FCP（First Contentful Paint）和 TTI（Time to Interactive）的变化：

// performance.js - 在关键路径添加性能测量
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(`${entry.name}: ${entry.duration.toFixed(2)}ms`)
  }
})
observer.observe({ entryTypes: ['measure', 'paint'] })

// 测量组件挂载时间
performance.mark('component-mount-start')
// ... 组件挂载 ...
performance.mark('component-mount-end')
performance.measure('Component Mount', 'component-mount-start', 'component-mount-end')

八、迁移检查清单

8.1 升级前检查

# 1. 确认当前 Vue 版本
npm list vue

# 2. 检查依赖兼容性
npm ls | grep -E "vue|@vue"

# 3. 检查是否使用了 Vapor Mode 不支持的 API
grep -r "getCurrentInstance\|app.config.globalProperties" src/

8.2 升级步骤

# 1. 备份当前代码
git branch backup-pre-3.6

# 2. 安装 Vue 3.6 beta
npm install vue@beta @vue/runtime-dom@beta @vue/runtime-vapor@beta

# 3. 启动开发服务器，观察是否有运行时错误
npm run dev

# 4. 运行测试套件
npm run test

# 5. 检查 Vapor Mode 兼容性问题
# 在关键组件上应用 <script vapor> 并测试

8.3 Vapor Mode 适用性评估

以下场景强烈推荐使用 Vapor Mode：

以下场景暂时保持 VDOM：

九、Vue 3.6 的战略意义

9.1 编译时优化的全面拥抱

Vue 3.6 标志着主流前端框架全面拥抱编译时优化的趋势：

• Svelte：从第一版就选择了编译时路线
• SolidJS：用细粒度响应式替代虚拟 DOM
• React：React Compiler 在编译时自动添加 use memo / useCallback
• Vue：Vapor Mode 彻底跳过虚拟 DOM

这不是巧合。当框架的抽象层足够稳定，当 TypeScript 的类型系统足够强大，当编译器的分析能力足够深入，编译时能做的工作就越来越多——而这些工作本就不应该在运行时做。

9.2 渐进式策略的又一次胜利

Vue 的聪明之处在于：它没有强制你放弃虚拟 DOM，而是让你按需选择。

你可以把 <script vapor> 当作一个性能优化的额外工具。对于不需要极致性能的场景，继续用 VDOM；对于性能瓶颈页面，换成 Vapor。零迁移成本，按组件粒度自由选择。

这种设计哲学，正是 Vue 从 2014 年诞生以来一直践行的核心理念：渐进式增强，而非激进革命。

9.3 前端性能竞赛的下一步

当所有框架都站在了"编译时优化 + 高效响应式"的同一起跑线上，竞争的焦点将从"性能数字"转向开发体验和生态建设：

• DevTools 能力：谁能提供更精准的性能分析工具
• SSR/SSG 优化：谁能更好地解决首屏加载问题
• AI 辅助开发：谁能更好地与 AI 编程工具集成
• 跨平台运行时：谁能更好地支持 Web、Native、Server 统一开发体验

Vue 3.6 赢得了一场性能战役，但真正的战争才刚刚开始。

十、总结

Vue 3.6 的两个核心变化，可以用一句话概括：

Vapor Mode 消除了渲染层的运行时开销，alien-signals 消除了响应式层的调度开销。

这两者加在一起，不是简单的性能优化，而是一次执行引擎的全面换血。从编译策略到数据结构，从调度算法到打包产物，Vue 在保持 100% 向后兼容的前提下，实现了性能上的量级跃迁。

对于 Vue 开发者来说，这是一个零门槛的性能红利。你不需要学习新语法，不需要重写现有代码，只需要在想优化的组件上加上 <script vapor>，就能立刻获得与 SolidJS 相当的性能。

而对于前端框架生态来说，Vue 3.6 的发布意味着：编译时优化已经成为行业共识，虚拟 DOM 的时代正在缓缓落幕。

参考资料

• Vue 3.6.0-beta.1 Release Notes
• alien-signals GitHub Repository
• vue-performance-compare Benchmark
• Vue Vapor Mode RFC
• js-framework-benchmark
• Vue 3.6 Beta Blog Post