詳解 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也是為了快，這是幾個意思？

vdom為什麼快？
要知道直接用原生才是性能最好的，為什麼對比直接用原生，有vdom會快，因為用vdom，再diff之後，會減少很多多餘的dom操作，儘管多了一層vdom，js層面計算量增大了，但dom api的調用少了，而對比這點js計算dom操作才是最大的性能消耗點，所以有vdom會比你直接原生開發性能普遍好。
（當然理論上，你的原生代碼要是能做到只做必要的dom操作，那確實性能更高）
為什麼現在取消vdom會快？
因為取消vdom，不是讓你直接原生寫，所以至少不會更慢，然後新的Vapor Mode為什麼更快，這個在下面會有詳細說明。

在之前vue中視圖更新的最小單位是組件，只要是render依賴的響應式數據變了，那render函數就會重新執行，重新生成vdom -> diff -> 真實渲染，這樣的方式在性能上有兩個瓶頸：

重新計算的多餘性能消耗
因為是整個組件一起重新計算出vdom，然後去更新，儘管在運行時vue對這塊兒已經做了很多優化，例如：組件級別的快取與跳過等，但無論如何都會有不必要的計算出現，最理想的情況應該是只重新計算直接依賴變化的響應式的數據的節點信息；
多餘的dom更新/生成
在重新計算出整個組件的vdom之後，這些vdom再拿去diff，然後把diff出來的vdom拿去真實渲染更新，但儘管diff算法已經優化成這樣了，但在某些場景下依然會產生多餘的dom更新/生成。

雖然vue之前也做了很多優化，但以上兩個問題依然是vdom模式所無法避免的問題，所以要達到無限接近原生的最優性能，只能逐步移除vdom模式。

二、為什麼Vapor Mode比Vdom 模式更快？

這個問題其實比較簡單，因為Vapor是元素級別的，類似svelte，響應式數據更新會去定點更新對應的元素，而不是整個組件一起更新，所以也就沒有vdom那些瓶頸。

三、沒有Vdom層，Vue怎麼解決跨平台問題？

要知道vdom模式的兩大優點就是：

減少多餘的dom更新，對比直接寫原生，性能提高
作為一層抽象，去描述UI，便於跨平台

以前的跨平台框架(uniapp等)是怎麼做的？
直接重寫Vue的渲染器，Vue默認提供的渲染器實現是瀏覽器api，所以其他平台只需要把渲染器這層用其他的api實現，移動端就用移動端那套來實現就行了。
現在沒有vdom來描述UI，那渲染器怎麼搞？
要理解這個的話，需要先知道vue中關於模板到渲染器去生成UI的整個運行機制。

其他節點，大家都比較清楚，關於“抽象層渲染代碼”這塊兒，我覺得可能需要單獨解釋一下，之前的理解中渲染器作用應該是vdom轉ui，但實際上在渲染器之前就會生成一層原子化的抽象層渲染代碼，渲染器的作用可以理解成是把這層抽象代碼轉成真實ui。
抽象代碼示意（並非真實編譯產物）：

<template>
    dkh
</template>

const text = createText('dkh');

// 具體實現放渲染器中
function createText(txt = '') {
 ....
}

可以看到這層抽象代碼其實是原子化的，所以可以看作在渲染器中，要做的就只是實現這些渲染函數，而不是單純的vdom轉ui的邏輯。
所以本來vdom轉ui這套邏輯已經是通過這層抽象渲染代碼解耦了的，所以即使移除了vdom，那些基於vue的跨端框架也無需大量的改動就能完成適配。而vue團隊關於這塊兒要做的也只是修改vdom轉抽象代碼的邏輯，這對下層開發者理論上也應該是無感的。