Vue Vapor
Vue Vapor 是 Vue 团队正在推进的一条实验路线。核心目标很直接：尽量绕开传统 VDOM diff，把组件编译成更细粒度、更直接的 DOM 更新逻辑。
这条路线很容易让人联想到 Solid.js，但 Vue Vapor 的重点并不是把 Vue 变成另一个 Solid，而是在尽量保留 Vue 心智和组合式 API 习惯的前提下，把运行时成本继续压低。
Vapor 在解决什么问题
传统 VDOM 模型已经很成熟，也足够通用，但它始终有一笔固定成本：
- 生成虚拟节点
- 做 diff
- 决定 patch 路径
当页面结构很复杂、状态变化很密集，或者运行环境本身比较吃紧时，这笔成本就会越来越显眼。
Vapor 的方向，就是尽量把更多工作提前到编译阶段做掉，让运行时只关注真正会变的那一小块。
它和 Vue 3 现有优化的关系
Vue 3 本身已经做了很多编译优化，比如：
- 静态提升
- Patch Flag
- Block Tree
Vapor 不是把这些推翻重来，而是继续沿着“多在编译期做判断、少在运行时兜底”的路线走得更远。
为什么这件事值得关注
这条路线如果成熟，会影响 3 件事：
- 大型界面的更新成本
- 首屏和交互时的运行时开销
- Vue 在高频更新场景下的性能上限
这也是为什么 Vue 官方一直没有把 Vapor 当成一个小实验来讲，而是持续投入原型、编译器和生态验证。
现在的状态
更稳妥的理解是：Vapor 仍然属于实验方向。
- 已经有独立原型和持续推进的代码仓库
- 方向明确
- 编译层思路清楚
- 但还不是“可以在常规生产项目里默认采用”的能力
尤其是下面这些能力，仍然需要持续观察：
- SSR / Hydration
KeepAliveTransition- 一些和运行时行为强耦合的高级特性
- 和现有生态工具的互操作性
适合现在怎么看待它
比较现 实的看法是：
- 值得了解
- 值得关注演进
- 不适合提前当成主线技术决策去押
如果当前目标是稳定交付业务，主线还是应该放在已经成熟的 Vue 3 能力上：<script setup>、宏能力、响应式、SSR、Hydration、TS 配合。
Vapor 更像 Vue 下一阶段性能路线的观察窗口。