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