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