你可能經(jīng)常聽到一個說法Vue 3 的性能比 Vue 2 提升了不少。但問得更具體一點快在哪里很多人第一反應(yīng)是“用了 Proxy”再深入一點就答不上來了。其實真正拉開差距的是編譯期和運行時的一整套配合優(yōu)化核心就三件事靜態(tài)提升、編譯時標記、運行時優(yōu)化。這篇文章我打算用大白話把這三板斧拆開講清楚。你不是非得懂編譯原理只要寫過幾天 Vue哪怕只寫過單文件組件也能看懂 Vue 3 的“性能秘密”到底藏在哪里。如果你最近在研究性能優(yōu)化、追性能問題追到頭禿或者準備從 Vue 2 遷到 Vue 3那這篇文章尤其適合你。1. 先把思路捋清楚為什么性能優(yōu)化從編譯期就開始1.1 真正要解決的是“重復(fù)勞動”Vue 的核心工作是數(shù)據(jù)變了視圖跟著變。它內(nèi)部維護一棵虛擬 DOM 樹每次數(shù)據(jù)變化之后用新的虛擬 DOM 和舊的做對比然后把差異更新到真實 DOM 上。Vue 2 時代這個對比是最讓人頭疼的。組件一旦更新整棵虛擬 DOM 樹都要從頭到尾比對一遍哪怕這一輪只改了某個按鈕里的一個文字其他所有節(jié)點也必須跟著“走個過場”。這就好比你家里每換一盞燈就要把所有房間的開關(guān)全部檢查一遍。燈多了、頁面復(fù)雜了檢查成本就上去了。Vue 3 的改變本質(zhì)上是把“檢查所有房間”變成了“只檢查有問題的房間”。關(guān)鍵是它憑什么知道哪個房間有問題答案不在運行時而在編譯期。模板不是隨便寫寫就運行的。Vue 的編譯器會把模板編譯成一段 render 函數(shù)同時做一次非常認真的“靜態(tài)分析”。哪些節(jié)點是永遠不會變的哪些節(jié)點只有文本會變哪些屬性是動態(tài)的哪些事件處理函數(shù)可以復(fù)用……這些信息在編譯階段就能拿到并且被直接寫進編譯產(chǎn)物里。運行時拿到這些“提前批注”的信息自然就能精準辦事。1.2 三大優(yōu)化各管一段這三板斧的分工很清晰靜態(tài)提升解決“反復(fù)創(chuàng)建相同對象”的問題減少內(nèi)存分配和垃圾回收壓力。編譯時標記解決“更新時不知道該從哪下手”的問題用二進制標記告訴 patch 算法節(jié)點類型。運行時優(yōu)化解決“diff 太慢”和“響應(yīng)式初始化太重”的問題升級 diff 算法、細化更新路徑。你可以把它理解成做一桌菜。靜態(tài)提升是提前把涼菜切好放在冰箱里客人來了直接端出來編譯時標記是在每盤菜上貼好標簽寫著“這盤要微波”“這盤直接上”運行時優(yōu)化是炒菜的時候只開必要的火絕不把所有灶臺都點燃。三個環(huán)節(jié)是配合關(guān)系。沒有編譯時標記運行時根本不知道哪些節(jié)點是靜態(tài)的沒有運行時優(yōu)化編譯期標記得再漂亮diff 依舊會走很多冤枉路。所以別把它們當成三個孤立的功能點。1.3 先看一個最終效果用一句話總結(jié)Vue 3 把能提前做的事全部提前到編譯期把能省的事全都在運行時省掉。所以你在寫模板的時候靜態(tài)內(nèi)容和動態(tài)內(nèi)容其實已經(jīng)被隱式分類了。模板里放一個p我是固定文案/p它不會跟著組件重新渲染而反復(fù)重建。模板里放一個{{ msg }}它也會被打上“動態(tài)文本”的標記更新時直接精確修改文本內(nèi)容。這種“以編譯器為主導(dǎo)、運行時積極配合”的思路是 Vue 3 性能提升的大前提。2. 靜態(tài)提升不變的節(jié)點只創(chuàng)建一次2.1 沒有靜態(tài)提升時有多浪費先說 Vue 2 的虛擬節(jié)點生命周期。組件 render 函數(shù)每執(zhí)行一次模板里的每個節(jié)點都會生成一個全新的虛擬節(jié)點對象。哪怕這個節(jié)點寫的是萬年不變的“確認”兩個字也會跟著每次 render 重新創(chuàng)建一個對象。對象創(chuàng)建本身不慢但架不住量大、頻率高。尤其是長列表、大頁面一次 render 可能產(chǎn)生幾千個虛擬節(jié)點數(shù)據(jù)頻繁變化時render 次數(shù)成千上萬創(chuàng)建出來的臨時對象都成了垃圾GC 壓力直接拉滿。你可能會在性能面板里看到一長串的 GC 耗時但完全不知道源頭在哪。2.2 Vue 3 的做法把靜態(tài)節(jié)點挪到 render 外面編譯器識別出模板里的靜態(tài)節(jié)點后會把它們的創(chuàng)建邏輯提取到 render 函數(shù)外部。render 函數(shù)每次執(zhí)行時直接引用同一個對象而不是重新創(chuàng)建。看一個最簡單例子。模板長這樣div p固定文本/p p{{ msg }}/p /div沒有靜態(tài)提升之前編譯產(chǎn)物大概是這樣的思路export function render(ctx) { return createVNode(div, null, [ createVNode(p, null, 固定文本), createVNode(p, null, ctx.msg) ]) }每次 render 執(zhí)行固定文本這個節(jié)點都會被重新 create 一次。有了靜態(tài)提升之后編譯產(chǎn)物變成這樣const _hoisted_1 createElementVNode(p, null, 固定文本, -1 /* HOISTED */) export function render(_ctx, _cache) { return (openBlock(), createElementBlock(div, null, [ _hoisted_1, createElementVNode(p, null, toDisplayString(_ctx.msg), 1 /* TEXT */) ])) }注意_hoisted_1被提升到了 render 函數(shù)外面。模塊加載時創(chuàng)建一次之后無論 render 執(zhí)行多少次都是復(fù)用同一個虛擬節(jié)點。后面那個-1是編譯標記里的一個特殊值專門用來標記“靜態(tài)提升節(jié)點”。運行時的 patch 邏輯看到它會直接跳過不做任何比較。2.3 什么樣的節(jié)點會被提升編譯器判斷“靜態(tài)”的條件比較嚴格。簡單來說節(jié)點自身以及它的所有子節(jié)點都不依賴任何響應(yīng)式數(shù)據(jù)才有可能被整體提升。比如p classname張三/p這種class 是靜態(tài)字符串文本也是寫死的整個節(jié)點都會被提升。但p classname{{ user.name }}/p就不會整體提升因為它的文本節(jié)點依賴響應(yīng)式數(shù)據(jù)user.name。不過編譯器內(nèi)部的優(yōu)化不止一層還有一些局部優(yōu)化比如某些靜態(tài)屬性、靜態(tài)子節(jié)點也會被單獨提取復(fù)用。經(jīng)驗上記住一個原則模板里能寫死的就別用變量。這既是為了讓靜態(tài)提升發(fā)揮作用也是為了讓編譯標記更精準。寫死的東西越多最終編譯出來的 render 函數(shù)里_hoisted變量就越多運行時需要對比的動態(tài)節(jié)點就越少。注意靜態(tài)提升的主要收益在“減少重復(fù)創(chuàng)建對象”和“減少 GC 壓力”上。它不是直接把 DOM 操作省掉別指望它讓首次渲染快一個數(shù)量級。真實的收益在更新頻繁的組件上體現(xiàn)得最明顯。3. 編譯時標記給每個虛擬節(jié)點貼一張“說明書”3.1 從全量 diff 到精準 diff如果只有靜態(tài)提升Vue 3 還不算真正的“精準打擊”。關(guān)鍵還在于編譯時生成的 patchFlag也就是補丁標記。這個標記是一個數(shù)字會被寫到虛擬節(jié)點的patchFlag字段上。運行時看到這個數(shù)字就知道這個節(jié)點在更新時到底需要處理什么。比如一個節(jié)點被打上1 TEXT標記運行時就知道這個節(jié)點只有文本內(nèi)容會變old text 和 new text 直接對比更新就行不需要關(guān)心它的 class、style、children 結(jié)構(gòu)有沒有變化。如果節(jié)點的標記是2 CLASS那更新時只需要檢查 class 屬性是否變化。標記的意義是減少無謂的比較分支讓 patch 邏輯走到最短路。我用一個生活類比來解釋?？爝f分揀中心每天處理大量包裹如果每個包裹都要拆開檢查里面是什么效率極低?，F(xiàn)在快遞單上提前印了“易碎”“生鮮”“普貨”之類的標簽分揀員不用拆就能快速分流。patchFlag 就是貼在虛擬節(jié)點上的快遞標簽。3.2 常見標記一覽Vue 3 里常用的幾個 patchFlag 如下標記值含義通俗解釋1TEXT只有文本內(nèi)容動態(tài)2CLASS只有 class 動態(tài)4STYLE只有 style 動態(tài)8PROPS部分 props 動態(tài)16FULL_PROPS完整 props 可能是動態(tài)的64STABLE_FRAGMENT穩(wěn)定的片段子節(jié)點固定128KEYED_FRAGMENT帶 key 的列表片段256UNKEYED_FRAGMENT不帶 key 的列表片段512NEED_PATCH需要執(zhí)行完整 patch1024DYNAMIC_SLOTS動態(tài)插槽-1HOISTED靜態(tài)提升節(jié)點不需要 patch你可能注意到標記值是 1、2、4、8、16……這不是隨便寫的是二進制位值。這樣設(shè)計是為了讓多個標記能組合在一個數(shù)字里。比如某個節(jié)點文本和 class 都動態(tài)那它的 patchFlag 可能是1 | 2按位或一下運行時用位與運算就能拆解非?？臁Ｉa(chǎn)環(huán)境的編譯器還會進一步優(yōu)化。開發(fā)模式下為了保留調(diào)試信息生成的代碼里會有額外注釋生產(chǎn)模式下注釋會移除代碼也更精簡。3.3 Block 樹把動態(tài)節(jié)點單獨收集起來光有標記還不夠Vue 3 還引入了一個叫 Block 的概念。我們知道 patchFlag 能告訴運行時“這個節(jié)點有某種動態(tài)”但父節(jié)點怎么知道自己的哪些子節(jié)點是動態(tài)的呢一個個遍歷找太費勁所以編譯器會把動態(tài)節(jié)點在創(chuàng)建時就收集到一個數(shù)組里?？粗澳嵌尉幾g產(chǎn)物里的openBlock()和createElementBlock它們就是在做這件事。openBlock()開啟一個 Block 的收集過程之后創(chuàng)建動態(tài)子節(jié)點時如果帶 patchFlag就會自動被收進當前 Block 的動態(tài)節(jié)點數(shù)組。最后 render 返回的虛擬節(jié)點上會掛著一個dynamicChildren數(shù)組。更新時運行時不需要遍歷整棵子節(jié)點樹只需要遍歷dynamicChildren這個數(shù)組。這就是為什么 Vue 3 的 diff 有時候看起來“跳著比”而不是老老實實逐層遞歸。樹的規(guī)模越大這個優(yōu)化越明顯。3.4 事件處理函數(shù)也被“緩存”了還有一個很容易踩坑的地方是事件處理函數(shù)。Vue 里寫clickhandleClick如果編譯器每次 render 都生成一個新的函數(shù)傳給子組件子組件用 props 對比時就會以為外部傳進來的 props 變了進而觸發(fā)不必要的重渲染。Vue 3 的編譯器會自動緩存事件處理函數(shù)。編譯產(chǎn)物里經(jīng)常能看到這樣的代碼onClick: _cache[0] || (_cache[0] $event _ctx.handleClick($event))第一次 render 時創(chuàng)建函數(shù)并存入_cache以后每次 render 都直接取緩存里的同一個函數(shù)。這個優(yōu)化和 patchFlag 不是一個體系但它同樣在靜默地幫你減少重復(fù)渲染。很多開發(fā)者以為 Vue 3 里子組件不會因為事件函數(shù)變化而更新是響應(yīng)式系統(tǒng)的功勞其實這里就有編譯器的功勞。4. 運行時優(yōu)化diff 算法和響應(yīng)式的底層變化4.1 從雙端 diff 到快速 diff虛擬 DOM 更新時最難的場景是列表。新舊兩個子節(jié)點數(shù)組要找出對應(yīng)關(guān)系決定哪些節(jié)點可以復(fù)用、哪些要移動、哪些要刪除、哪些要新增。Vue 2 用的是雙端 diff從新舊數(shù)組的頭和尾同時向中間比較通過四次首尾對比來盡量復(fù)用節(jié)點。這個算法在很多常見場景下表現(xiàn)不錯但中間部分一旦存在大量移動處理起來仍然繁瑣。Vue 3 的快速 diff 是先比較新舊列表的公共前綴和后綴這部分節(jié)點沒有變化就直接跳過。剩下中間那一段先把舊節(jié)點的 key 映射成一張查找表再根據(jù)新列表確定每個節(jié)點的位置關(guān)系最后用一個“最長遞增子序列”算法找出哪些節(jié)點不需要移動。你能不動就不動必須動的盡量少動。我舉個例子。舊列表是[A, B, C, D, E]新列表是[A, C, D, B, E]。公共前綴 A、公共后綴 E 直接跳過中間舊列表是[B, C, D]新列表是[C, D, B]。C、D 的相對順序在新舊列表里都沒變它們就不需要移動只需要把 B 移動到 D 后面。最長遞增子序列算法在這里找到的穩(wěn)定部分就是 C、D。DOM 移動次數(shù)從可能的兩三次降到了最少的范圍。4.2 key 不是隨便加加而已快速 diff 要正常工作key 至關(guān)重要。編譯器對帶 key 的列表會生成KEYED_FRAGMENT標記對沒有 key 的列表生成UNKEYED_FRAGMENT。沒有 key 的列表很難做精確的位置映射只能靠索引匹配很容易出現(xiàn)節(jié)點復(fù)用錯位導(dǎo)致狀態(tài)混亂。所以列表一定要加 key但不能用數(shù)組 index 當 key。用 index 在頭部插入一條數(shù)據(jù)時所有后續(xù)元素的 index 都會變化Vue 會認為它們?nèi)疾灰粯又荒艽罅啃遁d重建。正確做法是使用數(shù)據(jù)本身的穩(wěn)定 id比如用戶 id、訂單號。如果數(shù)據(jù)結(jié)構(gòu)里沒有唯一標識那就說明你的列表數(shù)據(jù)設(shè)計得有問題早發(fā)現(xiàn)早解決。4.3 響應(yīng)式系統(tǒng)也變“懶”了Vue 2 的響應(yīng)式初始化會把 data 里的對象遞歸遍歷一遍給每個屬性都加上 getter/setter。數(shù)據(jù)越復(fù)雜初始化成本越高。Vue 3 改用 Proxy 代理整個對象并且默認是懶遞歸——只有某個屬性被讀取時才會對下一層做依賴收集和代理。這就好比檢查一大箱貨物。Vue 2 是開箱把所有東西全部檢查登記一遍Vue 3 是先把箱子封上等真的有人來取某件貨時再打開那一層去處理。很多頁面數(shù)據(jù)很重但實際用到的字段有限懶代理的收益就很明顯。4.4 運行時不是獨立存在的運行時優(yōu)化的核心價值是配合編譯期信息。diff 算法再快也需要知道哪些節(jié)點真的需要 diff響應(yīng)式再快也需要避免把時間浪費在根本不會變化的節(jié)點上。正因為編譯器提前做了靜態(tài)分析運行時才能“指哪打哪”。這也是為什么 Vue 3 官方一直強調(diào)盡量寫模板而不是手動寫 render 函數(shù)。模板能經(jīng)過編譯器優(yōu)化手動 render 函數(shù)無法被靜態(tài)分析patchFlag 也不會自動生成。你當然可以在 render 函數(shù)里手工標記但這等于自己重新實現(xiàn)一遍編譯器的活很容易出錯。所以能用模板就用模板別跟編譯器對著干。5. 一個模板的完整編譯產(chǎn)物逐行看過去5.1 準備一個簡單的測試模板理論看多了容易飄我們把一個實際模板放進編譯器里看它到底變成了什么。下面是一個帶靜態(tài)文本、動態(tài)文本、動態(tài)屬性和事件的典型模板template div classprofile h2用戶信息/h2 p classname{{ user.name }}/p p{{ user.bio }}/p button clickupdateName改名/button /div /template這段代碼包含了靜態(tài)節(jié)點h2、動態(tài)文本節(jié)點、動態(tài)插值、以及一個事件綁定。編譯之后的產(chǎn)物大致如下經(jīng)過格式整理和生產(chǎn)模式簡化const _hoisted_1 /*#__PURE__*/ createElementVNode(h2, null, 用戶信息, -1 /* HOISTED */) export function render(_ctx, _cache) { return (openBlock(), createElementBlock(div, { class: profile }, [ _hoisted_1, createElementVNode(p, { class: name }, toDisplayString(_ctx.user.name), 1 /* TEXT */), createElementVNode(p, null, toDisplayString(_ctx.user.bio), 1 /* TEXT */), createElementVNode(button, { onClick: _cache[0] || (_cache[0] $event _ctx.updateName($event)) }, 改名) ])) }5.2 一段一段拆開看先看_hoisted_1。h2標簽、內(nèi)容是“用戶信息”完全靜態(tài)于是被提升到 render 函數(shù)外部。后面的-1就是 HOISTED 標記patch 階段直接忽略它。接著看兩個p。它們都帶1 /* TEXT */標記也就是動態(tài)文本節(jié)點。運行時拿到一個帶 TEXT 標記的節(jié)點后只會執(zhí)行“比較新舊文本、更新 textContent”的邏輯不會去重新處理 class、style 或者其他 props。第一個p雖然有靜態(tài) classname但因為它的文本子節(jié)點是動態(tài)的所以整個節(jié)點不會被提升只能帶著 TEXT 標記走常規(guī)創(chuàng)建流程。但創(chuàng)建之后更新階段還是只需要更新文本。再看button。注意onClick那里套了一個_cache[0]緩存。第一次 render 時創(chuàng)建事件函數(shù)并緩存之后所有 render 都復(fù)用同一個函數(shù)。這樣做的好處是如果這個按鈕組件化子組件不會因為父組件每次 render 傳入了“新函數(shù)”而被迫更新。根 div 沒有 patchFlag。它的 class 是靜態(tài)的所有需要處理的動態(tài)信息都已經(jīng)被收集到 Block 的dynamicChildren里。更新時運行時直接遍歷dynamicChildren不會遞歸地去比較h2、靜態(tài)文本這些節(jié)點。樹越深、靜態(tài)節(jié)點越多這個優(yōu)勢越明顯。5.3 怎么親眼驗證編譯產(chǎn)物如果你想知道自己寫的模板最終編譯成什么樣最簡單的方式是打開構(gòu)建產(chǎn)物搜索_hoisted、patchFlag、_cache這些關(guān)鍵詞。生產(chǎn)模式下代碼被壓縮搜索時可以用cache[0]或者hoisted片段定位。如果想單獨觀察某個模板也可以用一個空項目把模板寫進單文件組件里然后執(zhí)行一次生產(chǎn)構(gòu)建再打開輸出的 JS 文件。第一次看會有點不適應(yīng)但如果你能認出openBlock、createElementBlock、_hoisted這些結(jié)構(gòu)說明你已經(jīng)開始理解 Vue 3 的編譯思路了。這塊技能在排查性能問題時非常有用。6. 常見問題與避坑指南6.1 v-for 列表沒有寫 key這是很經(jīng)典的問題。編譯器對沒有 key 的列表會生成UNKEYED_FRAGMENT運行時只能按位置對比意味著列表里任意一個元素的順序變化都可能引起大范圍的重建。建議是所有 v-for 都寫 keykey 選穩(wěn)定且唯一的 id。不要用 index。如果后端沒有返回唯一 id試試組合字段比如type id但前提是組合后全局唯一且穩(wěn)定。6.2 模板里塞了太復(fù)雜的表達式模板表達式在每次 render 時都會重新執(zhí)行。如果你在模板里調(diào)用了一個三層嵌套、內(nèi)部循環(huán)幾百次的方法所有依賴這個方法的節(jié)點都會在每次更新時白等一次。正確的做法是把計算邏輯放進computed讓它在依賴變化時才重新執(zhí)行。靜態(tài)提升和編譯時標記救不了“每次渲染都要跑的重邏輯”因為編譯器只看結(jié)構(gòu)不看執(zhí)行時間。6.3 手動寫 render 函數(shù)丟了自動優(yōu)化Vue 3 對模板的優(yōu)化依賴編譯器的靜態(tài)分析。如果你用了 render 函數(shù)甚至用 JSX你就在跟編譯器說“這段你不用管了我自己來”。JSX 編譯也會有部分優(yōu)化但和模板對比仍然少了模板特有的靜態(tài)提升和標記生成。如果你不是特殊場景建議優(yōu)先用模板。6.4 性能問題的排查順序感覺組件變慢了不要上來就猜。先打開構(gòu)建產(chǎn)物看一眼編譯標記確認是不是模板寫法有問題再看響應(yīng)式依賴范圍是不是數(shù)據(jù)狀態(tài)設(shè)計得太寬最后用瀏覽器性能面板錄制一段交互看耗時落在哪個函數(shù)上。很多“Vue 變慢了”的問題最后查出來都是第三方組件太肥、網(wǎng)絡(luò)返回了大量沒用數(shù)據(jù)、或者自己在 watch 里做了重活。編譯器給的優(yōu)化再強也架不住你主動制造熱點。6.5 v-once 和 v-memo 要不要用v-once可以讓一段內(nèi)容只渲染一次適合極少數(shù)完全靜態(tài)的場景。但既然編譯器已經(jīng)有靜態(tài)提升了大部分靜態(tài)節(jié)點本來就會被自動處理手動加 v-once 的意義沒有你想的那么大。v-memo是按依賴值跳過更新的手段適合大列表里只有少量項變化的場景但用起來要小心依賴數(shù)組寫錯會導(dǎo)致視圖不更新。我的建議是先別急著上這些“手動擋”把模板結(jié)構(gòu)寫清晰、用對 key、把復(fù)雜邏輯移出模板收益通常比加優(yōu)化指令更大。寫在后面的一些體會我自己排查過幾次莫名其妙的重復(fù)渲染最后打開編譯產(chǎn)物一看問題往往不在 Vue 本身而在模板結(jié)構(gòu)。Vue 3 已經(jīng)把九九成的臟活提前干完了靜態(tài)提升、編譯時標記、快速 diff 這些設(shè)計平時你幾乎感知不到它們的存在。但當你真正去研究性能時你會發(fā)現(xiàn)這些優(yōu)化不是玄學(xué)而是一套環(huán)環(huán)相扣的工程決策。最后分享一個我常用的習(xí)慣每寫完一個組件我會花幾十秒打開生產(chǎn)構(gòu)建產(chǎn)物掃一眼這個組件的 render 函數(shù)?？此袔讉€_hoisted、哪些節(jié)點帶了 patchFlag、事件有沒有被緩存。這個習(xí)慣幫我避免了很多低級性能問題。你也可以試一次掃一眼不一定馬上看懂全部代碼但你會看到一個真實存在的“編譯優(yōu)化層”。這層?xùn)|西就是 Vue 3 性能提升的秘密所在。