Vapor Mode 不是银弹：性能好，但先看清这 14 条再上车
Vue 3.6 的 Vapor Mode 引入已经有一段时间了。社区讨论很多，但大多数人都卡在「好厉害」和「我该怎么用」之间。先说结论： Vapor 能带来实打实的性能提升，但它的限制清单同样明确。 它不替代虚拟 DOM，而是给你多一个选择。
Vapor 是什么：编译时把模板变成直接操作 DOM 的代码
Vapor Mode 的核心理念足够简单：编译时分析模板，直接生成操作真实 DOM 的 JavaScript 代码，跳过虚拟 DOM 节点的创建与 diff。 这意味着在运行时，Vapor 组件根本没有虚拟 DOM 参与。
第三方 benchmark 显示，Vapor 组件性能已达到与 Solid、Svelte 5 同级水平。官方数据的几个关键数字：
- 渲染速度最高提升 97%
- 包体积缩小 20-50%
- 首屏 JS 减少约三分之二
这些数字很漂亮，但要拿到它们，先要满足条件：你的组件必须运行在 Vapor 支持的范围内。 超出范围，Vapor 直接不能编译。
怎么启用：100% Opt-in，支持单组件接入
Vapor Mode 不是全局强制的东西。你可以只把某个高频组件切到 Vapor，其他保持虚拟 DOM 不动。启用方式包括：
- 单组件或全项目启用 Vapor 编译
- 纯 Vapor 应用使用新的实验性 API
createVaporApp()创建，不加载 Virtual DOM Runtime - 在虚拟 DOM 应用中，通过
vaporInteropPlugin引入 Vapor 组件，与 VDOM 组件混用
升级方面没有破坏性变更。从 Vue 3.5 升级到 3.6，现有代码不需要改动，Vapor 是逐步引入的。
关键限制清单：这些场景当前用不了
以下是 Vapor Mode 当前不可用的部分，来自官方文档和源码信息，版本更新可能会改变，以对应版本官方文档为准：
- 仅支持 Composition API 和 ``——Options API 组件无法使用 Vapor
- Teleport 暂不支持
- 凡依赖 Suspense 的组件树，需要继续使用虚拟 DOM
app.config.globalProperties不可用getCurrentInstance()不可用v-memo不支持- Template refs 不暴露
$el/$props/$attrs/$slots/$refs——依赖这些实例属性的代码会直接失效
所以一个很实际的判断方式：如果你的组件用了 Options API、Teleport、Suspense，或者依赖组件实例上的属性来操作 DOM，Vapor 当前不适合它。
同一版本里另一个变化：alien-signals 响应式引擎
Vapor Mode 之外，Vue 3.6 还引入了新的响应式核心 alien-signals，约 1KB，采用 Push-Pull 混合算法。官方 beta 确认的数据：
- 响应式性能比 3.5 快约 1.8 倍
- computed 吞吐量高出 30 倍
- 内存占用降低 65%
- 内存碎片化减少 82%
- 对象头从 48 bytes 压到 16 bytes
这项变化对现有虚拟 DOM 应用同样有效，不需要启用 Vapor 就能受益。换句话说，3.6 的响应式底层已经换代。
什么时候该用：用 Vapor 做高频，用 VDOM 管复杂
我的取舍建议很直接：
- 高频渲染的列表项、表格行、动态网格——Vapor 是明确收益方，性能提升明显，限制大多不涉及
- 依赖 Suspense、Teleport、Options API 的复杂业务组件——继续留在虚拟 DOM，别硬迁
- 纯 Vapor 新项目——可以用
createVaporApp()起步，但先确认整个组件树里没有上述限制项
Vapor 的定位不是「取代虚拟 DOM」，而是把选择权交还给你。虚拟 DOM 的灵活性和生态兼容性仍然有它的位置，Vapor 在你需要极致渲染性能的局部场景提供出口。
一句话总结
Vapor = 编译时出手，运行时减负。能用它的场景，性能收益明确；用不了它的场景，限制也写得很清楚。 升级到 3.6 是零成本的，用不用 Vapor 才是你需要决策的事。