详解 Vue 3.6 Vapor Mode:从原理到问题,看透 VDOM 逐步退场的底层逻辑

Vue 3.6 推试验性 Vapor Mode,逐步弃 VDOM!它凭元素级定点更新破 VDOM 性能瓶颈,借抽象代码兼容跨平台,却存编译压力与产物体积问题,带你看透 Vue 性能进化方向!

引言

2025/07/25日 vue conf中提到,vue3.6将可以开启Vapor Mode,逐步取消vdom

(目前vdom和vapor是兼容状态,估计vue4就彻底和vdom拜拜了)

Vapor的核心思想:

运行时vdom多余的计算取消,压力转到编译时;在编译后就直接生成了高效的渲染API

灵魂三问

一、为什么要干掉vdom?

还能是为什么,因为快啊(vdom模式有性能瓶颈)
前置解释:

ok,有朋友就要问了,以前用vdom是为了快,现在取消vdom也是为了快,你这是几个意思?

  1. vdom为什么快?
    要知道直接用原生才是性能最好的,为什么对比直接用原生,有vdom会快,因为用vdom,再diff之后,会减少很多多余的dom操作,尽管多了一层vdom,js层面计算量增大了,但是dom api的调用少了,而对比这点js计算dom操作才是最大的性能消耗点,所以有vdom会比你直接原生开发性能普遍好。
    (当然理论上,你的原生代码要是能做到只做必要的dom操作,那确实性能更高)
  2. 为什么现在取消vdom会快?
    因为取消vdom,不是让你直接原生写,所以至少不会更慢,然后新的Vapor Mode为什么更快,这个在下面会有详细说明。

在之前vue中视图更新的最小单位是组件,只要是render依赖的响应式数据变了,那render函数就会重新执行,重新生成vdom -> diff -> 真实渲染,这样的方式在性能上有两个瓶颈:

  1. 重新计算的多余性能消耗
    因为是整个组件一起重新计算出vdom,然后去更新,尽管在运行时vue对这块儿已经做了很多优化了,例如:组件级别的缓存与跳过等,但是无论如何都会有不必要的计算出现,最理想的情况应该是只重新计算直接依赖变化的响应式的数据的节点信息;
  2. 多余的dom更新/生成
    在重新计算出整个组件的vdom之后,这些vdom再拿去diff,然后把diff出来的vdom拿去真实渲染更新,但是尽管diff算法已经优化成这样了,但是在某些场景下依然会产生多余的dom更新/生成。

虽然vue之前也搞了特别多的优化,但是以上两个问题依然是vdom模式所无法避免的问题,所以要达到无限接近原生的最优性能,只能逐步移除vdom模式。

二、为什么Vapor Mode比Vdom 模式更快?

这个问题其实比较简单,因为Vapor是元素级别的,类似svelte,响应式数据更新,会去定点更新对应的元素,而不是整个组件一起更新,所以也就没有vdom那些瓶颈。

三、没有Vdom层,Vue怎么解决跨平台问题?

要知道vdom 模式的两大优点就是:

  1. 减少多余的dom更新,对比直接写原生,性能提高
  2. 作为一层抽象,去描述ui,便于跨平台

以前的跨平台框架(uniapp等)是怎么做的?

直接重写Vue的渲染器,Vue默认提供的渲染器实现是浏览器api,所以其他平台只需要把渲染器这层用其他的api实现,移动端就用移动端那套来实现就行了。

现在没有vdom来描述ui,那渲染器怎么搞?

要理解这个的话,需要先知道vue中关于模板到渲染器去生成UI的整个运行机制

其他节点,大家都比较清楚,关于"抽象层渲染代码"这块儿,我觉得可能需要单独解释一下,之前的理解中渲染器作用应该是vdom转ui,但是实际上在渲染器之前就会生成一层原子化的抽象层渲染代码,渲染器的作用可以理解成是把这层抽象代码转成真实ui。

抽象代码示意(并非真实编译产物):

vue 复制代码
<template>
    dkh
</template>
javascript 复制代码
const text = createText('dkh');

// 具体实现放渲染器中
function createText(txt = ''){
 ....
}

可以看到这层抽象代码其实是原子化的,所以可以看作在渲染器中,要做的就只是实现这些渲染函数,而不是单纯的vdom转ui的逻辑。
所以本来vdom转ui这套逻辑已经是通过这层抽象渲染代码解耦了的,所以即使移除了vdom,那些基于vue的跨端框架也无需大量的改动就能完成适配。而vue团队关于这块儿要做的也只是修改vdom转抽象代码的逻辑,这对下层开发者理论上也应该是无感的。

Vapor Mode目前的问题

OK,前面说了这么多,貌似Vapor应该是碾压Vdom,但是现在的Vapor Mode也只是试验阶段,依然也存在一些问题的。

  1. 把运行时Vdom的计算和转换等全部取消,把压力都给到了编译时,编译过程可能出问题且时间长
  2. 如果渲染的组件过多,可能会出现大量重复代码,导致编译产物体积过大

其实最主要的也是第二个问题,Svelte也有类似的问题,但是就目前的观察Vapor这个问题还没有很明显出现,另外就是vapor目前只是试验阶段,目前是vapor和vdom可以兼容,后面可能尤大看市场认可度比较高的话,就会在vue4中彻底移除vdom了吧。

最后感谢大家的阅读,以上是我个人关于Vapor的一些理解,可能有些说的不合适的地方,有不同见解的同学可以在评论一起探讨一下👍

相关推荐
崔庆才丨静觅6 小时前
hCaptcha 验证码图像识别 API 对接教程
前端
passerby60617 小时前
完成前端时间处理的另一块版图
前端·github·web components
掘了7 小时前
「2025 年终总结」在所有失去的人中,我最怀念我自己
前端·后端·年终总结
崔庆才丨静觅7 小时前
实用免费的 Short URL 短链接 API 对接说明
前端
崔庆才丨静觅8 小时前
5分钟快速搭建 AI 平台并用它赚钱!
前端
崔庆才丨静觅8 小时前
比官方便宜一半以上!Midjourney API 申请及使用
前端
Moment8 小时前
富文本编辑器在 AI 时代为什么这么受欢迎
前端·javascript·后端
崔庆才丨静觅8 小时前
刷屏全网的“nano-banana”API接入指南!0.1元/张量产高清创意图,开发者必藏
前端
剪刀石头布啊8 小时前
jwt介绍
前端
爱敲代码的小鱼8 小时前
AJAX(异步交互的技术来实现从服务端中获取数据):
前端·javascript·ajax