Vue 3.6 深度前瞻：Vapor Mode 与 alien-signals 如何重塑前端性能天花板

前言：2026年，前端框架的性能竞赛进入了一个全新的阶段。当 React 用 Compiler 做编译时优化、SolidJS 用细粒度响应式横扫 benchmark、Vue 依然坚守着虚拟 DOM——直到现在。Vue 3.6 的两个核心特性——Vapor Mode 和 alien-signals——正式宣告 Vue 从"够用"走向"极致"。本文将深入剖析这两个特性的技术原理、性能数据，并给出生产环境迁移策略。

一、虚拟 DOM 的十年统治与黄昏

1.1 一个时代的选择

2013年，Facebook（彼时还叫 Facebook）开源 React 时，引入了虚拟 DOM（Virtual DOM，简称 VDOM）概念。这个设计在当年是革命性的：在 JavaScript 内存中构建一棵虚拟节点树，每次数据变化时对比新旧两棵树（diff），找出最小差异，再批量更新真实 DOM。

这个方案解决了当时前端开发的一个核心痛点：直接操作 DOM 太慢、太频繁，而且容易出错。虚拟 DOM 提供了一个中间层，让开发者可以"声明式"地描述 UI，然后让框架负责计算最优的更新路径。

2016年 Vue 2.0 采纳虚拟 DOM 方案时，这一设计已经得到了充分验证。Vue 在 React 基础上做了大量工程优化——模板静态分析、静态提升、事件缓存、Block tree 等——将虚拟 DOM 的性能提升到了相当不错的水平。直到 Vue 3 的 Proxy 响应式系统和编译器优化组合，Vue 3 的性能在大多数场景下已经非常优秀。

但"够快"不等于"最快"。

1.2 虚拟 DOM 的结构性代价

让我们从工程层面理解虚拟 DOM 到底付出了什么代价：

第一，VNode 对象分配开销。每次组件渲染，都要生成一棵新的虚拟节点树。即便组件只需要更新一个文本节点，框架仍然要分配数十甚至数百个 VNode 对象。这在组件密集、数据频繁变化的场景下，GC（垃圾回收）压力不可忽视。

第二，diff 算法的必然成本。即便 Vue 3 已经通过 Block tree 和动态节点追踪（Dynamic Children）大幅减少了 diff 范围，算法复杂度仍然存在。O(n) 的递归比较在极端场景下会成为瓶颈。

第三，运行时依赖的包体积。虚拟 DOM 的运行时包括 VNode 构造器、diff 算法、patch 逻辑——即便经过 tree-shaking，这些代码在每个 Vue 应用中都占据可观的体积。

这三个问题在小型应用里几乎察觉不到，但在大型应用、复杂交互场景、高性能要求的场景下，就成了限制前端框架进一步突破的天花板。

1.3 编译时优化的崛起

过去两年，前端框架的性能竞赛出现了明确的方向转移：把尽可能多的工作移到编译时完成，减少运行时代码。

• Svelte 从诞生第一天就选择编译时路线——模板直接编译成精确的 DOM 操作代码，零运行时 VDOM 开销
• SolidJS 用 JSX + 细粒度响应式替代虚拟 DOM，编译时生成精确的 DOM 更新代码
• React 19 推出 React Compiler，在编译时自动插入 useMemo、useCallback，减少不必要的重新渲染
• Vue 3.6 推出 Vapor Mode，在保持模板语法的前提下，编译生成直接操作 DOM 的代码

2026年，"编译时优化"已经从一个边缘路线变成了主流共识。Vue 3.6 的 Vapor Mode 正是这个趋势的产物。

二、Vapor Mode：Vue 的"编译器革命"

2.1 核心原理：从 VNode 树到 DOM 指令

Vapor Mode 是 Vue 单文件组件（SFC）的第三种编译策略。在 Vue 3 中，SFC 编译有两种已有策略：

1. 开发版本（development）：生成带完整警告信息的 VNode 代码，便于调试
2. 生产版本（production）：通过 vue-tsc 或 Vite 压缩优化，但仍生成 VNode 树

Vapor Mode 是第三种策略——编译生成直接操作真实 DOM 的 JavaScript 代码，完全跳过 VNode 构造和 diff 流程。

传统 Vue 运行流程：

用户数据变化
    ↓
响应式系统通知组件重新渲染
    ↓
执行 render() 函数，生成新 VNode 树
    ↓
Vue 执行 diff 算法，对比新旧 VNode 树
    ↓
找出差异，patch（打补丁）到真实 DOM

Vapor Mode 运行流程：

用户数据变化
    ↓
响应式系统通知组件
    ↓
执行编译时生成的精确 DOM 操作指令
    ↓
直接修改真实 DOM（无 VNode，无 diff）

2.2 启用方式：极简的迁移路径

Vapor Mode 的设计哲学是渐进式采用——不是全有或全无，而是可以精确到每个组件单独启用。

方式一：<script vapor> 属性（推荐）

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

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

<template>
  <div class="counter">
    <h1>Count: {{ count }}</h1>
    <p>Doubled: {{ doubled }}</p>
    <button @click="count++">Increment</button>
  </div>
</template>

编译后生成的代码（简化示意）：

// Vue 编译器生成的 Vapor 模式代码（示意）
const count = signal(0)
const doubled = computed(() => count.value * 2)

function render() {
  // 精确的 DOM 操作，无 VNode，无 diff
  _el(0).textContent = count.value
  _el(1).textContent = doubled.value
}

effect(() => render())

方式二：文件名约定（无需修改源码）

MyComponent.vapor.vue  → 自动启用 Vapor Mode
MyComponent.vue        → 传统 VDOM 模式

方式三：createVaporApp() 构建纯 Vapor 应用

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

// 创建纯 Vapor 应用，零 VDOM 运行时
createVaporApp(App).mount('#app')

这种方式下，打包产物完全不包含 VDOM 相关代码——包体积可以缩减 20-50%。

2.3 性能数据：量变到质变

Vapor Mode 在业界权威的 js-framework-benchmark 中的表现让很多人感到意外：

100ms 挂载 10 万个组件——这个数字意味着 Vue 已经进入了 SolidJS 和 Svelte 5 的同一性能梯队。这不是一个渐进式优化，而是一个量级的飞跃。

2.4 与传统模式的混合使用

Vapor Mode 的最大工程价值在于它可以与现有 VDOM 应用共存。这在 Vue 团队的设计中被称作 "vaporInteropPlugin"：

import { createApp } from 'vue'
import { vaporInteropPlugin } from '@vue/vapor-interop'
import App from './App.vue'  // 传统 VDOM 应用

createApp(App)
  .use(vaporInteropPlugin)  // 允许在树中渲染 Vapor 组件
  .mount('#app')

这种设计让团队可以在不重写现有应用的情况下：

• 对性能瓶颈页面单独启用 Vapor 组件
• 新增功能时使用 Vapor 模式
• 逐步将高频渲染组件迁移到 Vapor 模式

2.5 当前限制与注意事项

截至 2026 年 7 月（Vue 3.6 beta.17），Vapor Mode 仍有以下限制需要关注：

使用限制：

• 仅支持 Composition API：Options API 组件无法使用 Vapor Mode
• getCurrentInstance() 不可用：依赖实例 API 的组件无法迁移
• app.config.globalProperties 不适用：全局属性注入无法工作
• Suspense 暂不支持：但可以在 VDOM Suspense 中渲染 Vapor 组件
• Slots 行为差异：<slot> 渲染方式不同，slots.default() 在 Vapor 模式下不可用

兼容性问题：

• 需要等待第三方组件库（Element Plus、Vuetify 等）适配
• SSR hydration 已支持，但 Nuxt 兼容性仍在完善中
• 与某些依赖 VDOM 实例 API 的库（如某些动画库）可能存在边界问题

官方建议：当前阶段适合在现有应用中对性能敏感的子页面使用 Vapor Mode，或者用 Vapor Mode 构建全新的小型应用。不建议大规模迁移现有组件，建议等待正式版发布后再做决策。

三、alien-signals：1KB 响应式核心的性能革命

3.1 一个 1KB 库的逆袭故事

如果说 Vapor Mode 是一台新引擎，那么 alien-signals 就是这台引擎的核心燃料。

alien-signals 由 Vue 核心贡献者 Johnson Chu 创建。它的诞生源于一个研究问题：Vue 3.5 的响应式系统已经采用了 Pull-based（拉取式）算法，能否进一步探索 Push-Pull 混合算法的可能性？

Johnson Chu 决定将这个研究独立为一个独立的微型库进行实验。这个库在压缩后只有 1KB，但因为实验结果太过出色——最终被直接移植回了 Vue 3.6 的核心代码库。

这不是一个闭门造车的"学术玩具"，而是一个经过大量微观基准测试验证、在生产环境中被证明有效的算法。

3.2 Push-Pull 混合算法：两个世界的最佳特性

理解 alien-signals 的性能优势，关键在于理解 Push-Pull 混合算法。

纯 Push 模式（早期响应式系统常用）：

// signal 变化时，立即触发所有下游重新计算
const count = signal(1)
const doubled = computed(() => count() * 2)

// count(2) → doubled 自动重新计算，立即
// 优点：值永远最新
// 缺点：即便没人读取也执行大量计算，浪费

纯 Pull 模式（React 的 useMemo 属于此类）：

// signal 变化时什么都不做，读取时才检查
const doubled = useMemo(() => count * 2)

// 优点：只计算用到的值
// 缺点：每次读取都要检查是否需要重新计算，额外开销

alien-signals 的 Push-Pull 混合模式：

// signal 变化 → Push: 只传播"dirty"标志，不执行计算
// computed 读取 → Pull: 检查 dirty 标志，必要时才重新计算
count(2)  // Push: 设置 dirty 标记，O(1) 操作
doubled()  // Pull: 发现 dirty，重新计算

Push 阶段只传播"需要更新"的标志，不执行任何实际计算。Pull 阶段只在真正需要时才执行重算。 这带来了两个世界的最佳特性：既不会浪费计算资源在无人读取的值上，也不会在每次读取时都做昂贵的检查。

3.3 双向链表依赖追踪

alien-signals 在依赖管理上选择了双向链表，而非传统的 Set/Map。这不是"重新发明轮子"，而是基于性能考量的精确选择：

// 传统的 Set 依赖追踪
// 每个依赖添加/删除：O(log n)，需要哈希计算
// 遍历：O(n)，哈希遍历

// 双向链表依赖追踪
// 每个依赖添加/删除：O(1)，指针操作
// 遍历：O(n)，线性遍历
// 全局版本标记（globalVersion）：O(1) 脏检查

配合 版本标记脏检查机制（globalVersion），alien-signals 可以在 O(1) 时间复杂度内判断某个 computed 的依赖是否过期，避免了不必要的重复计算。

3.4 刻意为之的设计约束

alien-signals 在实现上施加了几个刻意为之的约束，这些约束正是它性能出色的关键所在：

// 约束一：核心遍历不使用 Array/Set/Map
// 避免额外的内存分配和 GC 压力
// 使用链表节点替代

// 约束二：禁止函数递归
// 避免调用栈开销和栈溢出风险
// 使用循环替代递归

// 约束三：位运算状态标志
// 用紧凑的位标志代替单独的布尔字段
const FLAG_DIRTY = 1 << 0
const FLAG_STALE = 1 << 1
const FLAG_RUNNING = 1 << 2

// 约束四：类属性少于 10 个
// 符合 V8 快速属性访问（Fast Properties）的优化条件

这些约束看起来有些"极端"，但实验结果表明：在响应式系统的性能关键路径上，保持算法的简洁性比复杂的调度策略能带来更显著的性能提升。

3.5 性能对比：数字说明一切

来自社区基准测试项目 vue-performance-compare 的数据（200,000 refs、100,000 computed、20,000 effects）：

Vue 官方在 beta 发布说明中确认的数字更加惊人：响应式性能比 Vue 3.5 快约 1.8 倍，computed 吞吐量高出 30 倍以上，内存占用降低 65%。

30 倍不是笔误。 在大量读取 computed 值的场景下（如列表渲染中的派生数据），alien-signals 的吞吐量是 Vue 3.5 的 30 倍以上。这不是微优化，而是算法级别的量变。

3.6 alien-signals 的核心 API

alien-signals 的 API 设计极度精简，只需三个核心函数：

import { signal, computed, effect } from 'alien-signals'

// signal：响应式数据容器
const count = signal(0)

// 读取（作为函数调用）
console.log(count())  // 0

// 写入
count(1)

// computed：惰性求值的派生值
const doubled = computed(() => count() * 2)
// 只有在读取时才会触发计算
console.log(doubled())  // 2

// effect：响应式副作用
effect(() => {
  console.log(`Count changed to: ${count()}`)
})
// Count changed to: 1
// 依赖 count，当 count 变化时自动执行

注意 alien-signals 的 API 与 Vue 3.5 的响应式 API 有细微差异：signal() 是函数而非对象，computed() 的写法也略有不同。Vue 3.6 会在内部集成 alien-signals 的核心算法，但对外暴露的 API 仍保持与 Vue 3.5 一致的接口。

四、双引擎合璧：Vue 的"性能换芯"工程

4.1 两条独立的技术演进线

理解 Vue 3.6 的变革，最好的比喻是**"换了两台引擎"**：

引擎一：Vapor Mode（换掉渲染引擎）

传统 VDOM 渲染：模板 → VNode 树 → diff → DOM patch

Vapor Mode：模板 → 精确 DOM 操作指令 → 直接 DOM 修改

两者解决的痛点不同：VDOM 渲染解决的是"跨平台抽象"和"开发体验"；Vapor Mode 解决的是"极致性能"。Vue 3.6 让开发者可以按需选择。

引擎二：alien-signals（换掉响应式引擎）

Vue 3.5 响应式：Proxy + 纯 Pull 算法

Vue 3.6 响应式：Proxy + Push-Pull 混合算法（alien-signals）

alien-signals 的集成是透明的——不需要修改任何代码，所有 Vue 3 应用在升级到 3.6 后自动获得性能提升。

4.2 打包体积的实际影响

对于最终用户而言，Vapor Mode 带来的打包体积优化是实打实的：

一个包含 50 个组件的典型 Vue 3 应用（使用 Vite 构建）：

传统模式打包产物：
  vue.runtime.esm-bundler.js  ~33KB (gzip)
  运行时总计（包含 VDOM）     ~45KB (gzip)

Vapor Mode 模式打包产物：
  vue.vapor.esm-bundler.js    ~11KB (gzip)  
  运行时总计（无 VDOM）       ~18KB (gzip)

减少约 27KB gzip——在移动端网络条件下，这可能意味着 100-200ms 的加载时间差异。

对于组件密集的 dashboard 类应用、实时数据展示系统、高频交互的 SaaS 产品，这个体积差异会产生可感知的性能提升。

五、生态影响：一场静悄悄的变革

5.1 Nuxt 生态

Nuxt 4 正在紧锣密鼓地适配 Vue 3.6 新特性。关键路径是 SSR（服务端渲染）hydration 的稳定性：

// Nuxt 4 预期用法（伪代码）
// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    vaporMode: true  // 一键开启 Vapor SSR
  }
})

当 Vapor Mode 的 SSR hydration 完全稳定后，Nuxt 项目将可以无缝使用 Vapor Mode。服务端渲染 + 编译时优化的组合将进一步提升全栈应用的 TTFB（首字节时间）和 FCP（首次内容绘制）指标。

5.2 组件库生态

现有的 Vue 组件库（Element Plus、Vuetify、Ant Design Vue、Naive UI 等）目前仍基于传统 VDOM 模式编写。Vapor Mode 的出现并不意味着这些库需要立即重写——恰恰相反，组件库的维护者可以采取渐进式迁移策略：

<!-- Element Plus Table 组件，内部高频渲染部分使用 Vapor -->
<el-table :data="tableData">
  <!-- 表格行（高频渲染）→ Vapor 组件 -->
  <!-- 分页控件（低频渲染）→ 传统 VDOM -->
</el-table>

从实践角度看，表格行、列表项、虚拟滚动项等高频渲染场景是最值得优先迁移到 Vapor Mode 的部分。

5.3 状态管理

Pinia 是 Vue 官方推荐的状态管理库。Pinia 的响应式追踪机制与 Vue 的响应式系统深度绑定——这意味着 alien-signals 的性能提升会自动传递到 Pinia。

Pinia 3（规划中）可能会在底层进一步利用 alien-signals 的 Push-Pull 特性，减少 storeToRefs 和 watch 的开销。对于使用 Pinia 管理大量状态的应用，这是一个值得期待的性能红利。

5.4 DevTools 的变化

Vapor Mode 组件在 Vue DevTools 中的调试体验与传统组件有所不同。由于没有 VNode 树，传统的"组件检查器"视图需要重新设计。Vue 团队正在为 DevTools 开发新的 Vapor Mode 调试面板，预计与 3.6 正式版同步发布。

六、生产环境迁移策略

6.1 第一步：尝鲜 alien-signals（零风险）

alien-signals 的集成是自动的。只需升级 Vue 版本，即可获得响应式性能提升：

# 安装 Vue 3.6 beta
npm install vue@beta

# 验证版本
node -e "const vue = require('vue'); console.log(vue.version)"
# 输出: 3.6.0-beta.x

这一步骤不需要修改任何业务代码。Vue 3.6 在 API 层面对 Vue 3.5 完全向后兼容——signal、ref、computed、watch、effect 的用法保持不变。你可以在生产环境中安全地尝试这一步骤，观察性能指标的变化。

6.2 第二步：识别 Vapor Mode 候选组件

以下场景最适合使用 Vapor Mode：

高优先级候选：

• 包含大量 v-for 列表的组件（虚拟列表、数据表格）
• 需要毫秒级响应的高频交互组件（股票行情、游戏 UI）
• 渲染次数频繁的实时数据展示组件
• 首屏性能敏感的落地页组件

低优先级候选（暂不迁移）：

• 使用 Options API 的历史组件
• 依赖 getCurrentInstance() 或 app.config.globalProperties 的组件
• 使用第三方依赖 VDOM 实例 API 的组件
• SSR hydration 尚未稳定的复杂组件树

6.3 第三步：渐进式迁移示例

假设你有一个订单列表组件，包含了高频刷新的数据行：

<!-- OrderList.vue (传统模式) -->
<script setup>
import { ref, computed } from 'vue'

const orders = ref([])
const filter = ref('all')

const filteredOrders = computed(() => {
  return filter.value === 'all' 
    ? orders.value 
    : orders.value.filter(o => o.status === filter.value)
})
</script>

<template>
  <div class="order-list">
    <div class="filter-bar">
      <button @click="filter = 'all'">全部</button>
      <button @click="filter = 'pending'">待处理</button>
    </div>
    <div v-for="order in filteredOrders" :key="order.id">
      <OrderRow :order="order" />
    </div>
  </div>
</template>

迁移到 Vapor Mode 的路径：

<!-- OrderList.vapor.vue -->
<script vapor>
import { signal, computed } from 'vue'

const orders = signal([])
const filter = signal('all')

const filteredOrders = computed(() => {
  return filter.value === 'all' 
    ? orders.value 
    : orders.value.filter(o => o.status === filter.value)
})
</script>

<template>
  <div class="order-list">
    <div class="filter-bar">
      <button @click="filter.value = 'all'">全部</button>
      <button @click="filter.value = 'pending'">待处理</button>
    </div>
    <!-- v-for 在 Vapor Mode 下会被编译为精确的列表更新指令 -->
    <OrderRow 
      v-for="order in filteredOrders" 
      :key="order.id" 
      :order="order" 
    />
  </div>
</template>

主要变化：

• <script setup> → <script vapor>
• ref() → signal()（虽然 ref 也能工作，但 signal 更符合 Vapor 语义）
• filter = 'pending' → filter.value = 'pending'（signal 的写入方式是函数调用）
• <OrderRow> 组件需要确认是否也支持 Vapor Mode

6.4 第四步：测试与验证

Vapor Mode 的引入应该在 CI/CD 流程中有对应的测试策略：

// tests/e2e/vapor-performance.spec.ts
import { test, expect } from '@playwright/test'

test.describe('Vapor Mode Performance', () => {
  test('列表渲染 1000 项应在 50ms 内完成', async ({ page }) => {
    await page.goto('/order-list')
    await page.waitForSelector('.order-list')
    
    const start = performance.now()
    await page.locator('[data-testid="load-more"]').click()
    await page.waitForTimeout(100) // 等待渲染完成
    
    const duration = performance.now() - start
    expect(duration).toBeLessThan(50)
  })
})

七、前端框架性能竞赛的新格局

7.1 2026 年的框架性能图谱

Vue 3.6 的发布重新定义了前端框架性能竞争的分水岭：

性能梯队（2026年7月）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第一梯队（Svelte 5 同级）：
  Vapor Mode Vue 3.6  |  SolidJS  |  Svelte 5
  特点：编译时优化 + 零 VDOM 运行时
  
第二梯队（传统 VDOM 优化极限）：
  Vue 3.5            |  React 19 (RSC)
  特点：虚拟 DOM + 编译时辅助优化
  
第三梯队（历史版本）：
  Vue 2             |  React 17 及以下
  特点：VNode diff 性能有结构性上限
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

7.2 Vue 的战略选择：渐进优于激进

与 SolidJS 和 Svelte 5 的激进路线不同，Vue 3.6 选择了渐进式路线：

SolidJS：要求完全放弃 VDOM，用 JSX + 细粒度响应式替代。性能极致，但迁移成本极高。

Svelte 5：引入 runes（$state、$derived、$effect）作为新的响应式原语，语法与 Svelte 4 差异较大。

Vue 3.6：Vapor Mode 和 alien-signals 都可以独立采用——你可以：

• 只升级 Vue 版本，享受 alien-signals 带来的响应式提速（零迁移成本）
• 选择性地将某些组件迁移到 Vapor Mode（按需迁移）
• 继续使用传统 VDOM 模式，应用依然正常运行

这种设计哲学与 Vue 一贯的"渐进式框架"理念完全一致：不强迫开发者做任何事情，让他们在自己的节奏下享受技术进步。

7.3 虚拟 DOM 的未来

虚拟 DOM 不会在短期内消失。它在以下场景仍有不可替代的价值：

• 需要跨平台渲染（Web、SSR、Native）：React Native、Weex 等平台复用 VNode 抽象层
• 复杂的动态渲染逻辑：高度动态的 UI，模板无法在编译时完全分析
• 庞大而成熟的代码库：迁移成本高于继续使用 VDOM 的收益

但 Vapor Mode 的出现揭示了一个清晰的方向：当编译时分析足够强大时，虚拟 DOM 的运行时开销就从"可以接受"变成了"可以避免"。

八、总结与展望

8.1 Vue 3.6 的核心价值

Vue 3.6 的两个核心特性代表了前端框架演进的一个里程碑时刻：

Vapor Mode：让 Vue 拥有了与 SolidJS、Svelte 5 同等的极致渲染性能，同时保持了 Vue 的模板语法和开发体验。这不是追赶，而是迎头赶上。

alien-signals：用 1KB 的核心算法，实现了响应式性能的量级提升。30 倍的 computed 吞吐量提升，意味着 Vue 应用在处理复杂派生数据时可以更加从容。

两者结合：Vue 3.6 在保持 100% 向后兼容的前提下，让开发者可以根据场景自由选择性能路径。这正是 Vue "渐进式"设计哲学的最好体现。

8.2 给开发者的建议

现在应该做什么：

1. 在测试环境中升级 Vue 3.6 beta，观察性能指标和兼容性
2. 用 js-framework-benchmark 对比你的应用场景的实际性能
3. 识别适合 Vapor Mode 的候选组件，提前做好迁移方案

现在不要做什么：

1. 不要立即大规模迁移现有组件到 Vapor Mode（beta 版本仍有风险）
2. 不要因为"新版本发布"而制造焦虑——Vue 3.5 已经非常优秀
3. 不要忽视 alien-signals 的 API 细微差异（signal 的函数调用写法）

关注的时间节点：

• 关注 Vue 3.6 正式版发布时间（目前仍在 beta 阶段）
• 关注 Nuxt 4 对 Vapor Mode 的官方支持公告
• 关注 Element Plus、Vuetify 等主流组件库的 Vapor 适配计划

8.3 一个更长远的视角

站在 2026 年的节点向前看，前端框架的性能竞赛已经进入了一个新阶段：不是谁更快，而是谁能在保持开发体验的同时达到极致性能。

在这个阶段，框架的选择将更加取决于团队的技术栈熟悉度、生态系统成熟度和长期维护成本——而非单纯的 benchmark 分数。Vue 3.6 的 Vapor Mode 给了 Vue 开发者一张进入"极致性能俱乐部"的入场券，同时让他们可以带着现有的代码存量优雅地入场。

这，才是 Vue 3.6 真正重要的原因。

参考资料

• 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 发布公告