做過前端的人應(yīng)該都聽說過 AST也天天在用渲染但“從 AST 到渲染”中間到底發(fā)生了什么很多人是模糊的。尤其是當(dāng)你開始寫插件、做視圖替換、調(diào)試一些詭異問題的時候這條鏈路的理解直接決定你能不能找到問題的根因。這篇文章我用實際項目的視角把這條鏈路從原理到實操拆開講清楚講一講插件到底在哪個時機起作用以及我們常說的視圖替換有幾種實現(xiàn)路徑、各自坑在哪里。這個話題適合正在學(xué) Vue/React 原理、被構(gòu)建工具插件折磨過、或者想寫自定義編譯器/模板插件的前端開發(fā)者。如果你只是天天寫業(yè)務(wù)組件讀這篇文章也能幫你理解為什么某些寫法性能差、為什么有的報錯看起來莫名其妙。1. 從源碼到 AST一切工程化的起點1.1 為什么所有框架都繞不開 AST先做個類比。AST 之于代碼就像語法樹之于自然語言。你在讀英文句子時大腦會把它拆成主謂賓拆成從句拆成修飾關(guān)系。編譯器拿到源碼后第一步就是做類似的事——它把字符串形式的代碼按語法規(guī)則拆成一棵結(jié)構(gòu)化的樹。這棵樹就是 ASTAbstract Syntax Tree抽象語法樹。為什么要費勁搞這么一棵樹因為字符串只能做文本級操作沒法做語義級操作。比如我想知道“這段代碼聲明了哪些變量”如果你用正則去匹配字符串會漏掉注釋里的假變量、模板字符串里的變量、作用域遮蔽的情況而且不同書寫風(fēng)格幾乎沒法統(tǒng)一處理。但 AST 是結(jié)構(gòu)化的每個節(jié)點有類型、有父子關(guān)系、有位置信息我可以從根節(jié)點往下遍歷精確數(shù)出每一層作用域里的聲明。我舉個例子const a 1這句代碼對應(yīng)的 AST 大概長這樣{ type: VariableDeclaration, kind: const, declarations: [ { type: VariableDeclarator, id: { type: Identifier, name: a }, init: { type: Literal, value: 1 } } ] }這種結(jié)構(gòu)讓程序可以精準(zhǔn)地知道這是一個變量聲明聲明方式是 const變量名叫 a初始值是 1。想改變量名遍歷找到所有 Identifier 為 a 的節(jié)點逐個修改。想給所有函數(shù)加一段日志找到 FunctionDeclaration 節(jié)點往函數(shù)體里插入子節(jié)點。這正是所有編譯工具、Lint 工具、格式化工具、代碼高亮、編輯器智能提示的基礎(chǔ)設(shè)施。沒有 AST現(xiàn)代前端工程化里的一大半工具都要重新設(shè)計。1.2 解析器的兩個階段詞法分析和語法分析整個解析過程在編譯器術(shù)語里通常分兩步詞法分析和語法分析。詞法分析把字符流切成 Token相當(dāng)于把一句話切成一個個有意義的單詞語法分析再把 Token 根據(jù)語法規(guī)則組裝成樹相當(dāng)于確定單詞之間的語法關(guān)系。我拿const a 1 2舉例。詞法分析階段會得到一串 Token[ { type: keyword, value: const }, { type: identifier, value: a }, { type: operator, value: }, { type: number, value: 1 }, { type: operator, value: }, { type: number, value: 2 } ]語法分析階段就會把這幾個 Token 組織成一個有層級的結(jié)構(gòu)頂層是 VariableDeclaration里面嵌套 BinaryExpression1 2BinaryExpression 的 left 和 right 分別是兩個 Literal 節(jié)點。這兩個階段的劃分意義不只是理論上的。做插件開發(fā)時你會經(jīng)常遇到某些錯誤發(fā)生在詞法階段比如字符串沒閉合某些錯誤發(fā)生在語法階段比如花括號不匹配還有一些發(fā)生在后續(xù)的遍歷轉(zhuǎn)換階段比如你插件代碼自己寫錯了去讀取某個不存在的字段。能區(qū)分錯誤發(fā)生在哪個階段排查效率會高很多。1.3 AST 不只是編譯器的專利很多人以為 AST 只在轉(zhuǎn)譯器里出現(xiàn)其實它滲透在幾乎所有前端工具里ESLint每條規(guī)則本質(zhì)上是一個 AST 訪問器。你在 eslint 配置文件里寫的no-unused-vars就是規(guī)則庫在遍歷 AST 時檢查變量聲明節(jié)點和引用節(jié)點的聯(lián)通關(guān)系。Prettier把代碼解析成 AST 之后無視你原本怎么換行縮進(jìn)直接按模板重新打印出來。代碼高亮用正則做基元匹配很容易誤傷字符串內(nèi)容基于 AST 做分詞才能區(qū)分什么是真正的關(guān)鍵字、什么是字符串里的普通文本。IDE 智能提示跳轉(zhuǎn)到定義、查找引用都是基于 AST 建立的索引。瀏覽器本身也是這個套路。JS 引擎V8、SpiderMonkey 等拿到 JS 源碼后第一件事也是解析成 AST再轉(zhuǎn)成字節(jié)碼、機器碼。所以“從 AST 到渲染”這條鏈路其實有兩層一層是瀏覽器引擎從 JS 源碼到頁面渲染另一層是前端框架從模板/JSX 到虛擬 DOM 再到真實 DOM。我們平時接觸最多的、插件也最常介入的是后一層。2. 從 AST 到渲染編譯器與運行時的分工2.1 編譯時與運行時的邊界在哪里“渲染”這個詞含義比較廣。瀏覽器渲染流水線是 HTML/CSS/JS 經(jīng)過解析、樣式計算、布局、繪制、合成最終上屏。而前端框架視角下的渲染通常指的是用戶寫的組件模板/代碼如何變成真實可見的 DOM。這中間一般分兩步走。第一步是編譯時。Vue 的模板、JSX、TSX 這些“帶增強語法的源碼”通過編譯器的解析和轉(zhuǎn)換變成可執(zhí)行的 JavaScript 渲染函數(shù)。第二步是運行時?？蚣苷{(diào)用這些渲染函數(shù)生成虛擬節(jié)點vnode再通過 diff 和 patch 算法更新到真實 DOM 上。這兩步的邊界不是固定的不同框架選擇不一樣React 的 JSX 編譯后Babel/ESBuild/SWC 插件運行時通過React.createElement調(diào)用創(chuàng)建元素描述對象。Vue 3 的模板編譯后生成的渲染函數(shù)直接調(diào)用createElementBlock等底層 API運行時用精心設(shè)計的 patch 邏輯更新。Svelte 干脆把組件編譯成非常命令式的原生 DOM 操作代碼運行時幾乎不需要框架參與 diff。邊界怎么畫核心在于“哪些工作在編譯時做死”哪些工作留到運行時動態(tài)決定。編譯時做得越多運行時壓力越小但靈活性越低運行時越通用越靈活但要做更多判斷、性能開銷更大。2.2 模板編譯的完整鏈路我以 Vue 3 為例把這條鏈路走一遍因為它在編譯器結(jié)構(gòu)上最清晰而且文檔里有 AST explorer 可以直接觀察每一步的輸出。模板源碼div classbox p{{ msg }}/p span v-ifshowHello/span /div第一步解析器將這個模板字符串解析成 AST。節(jié)點類型包括 Element 節(jié)點div、p、span、屬性節(jié)點class、v-if、插值節(jié)點{{ msg }}。注意這里的 AST 不是 JS 的 AST而是模板 AST節(jié)點由模板語法決定的。第二步轉(zhuǎn)換階段。編譯器會遍歷模板 AST做靜態(tài)分析識別哪些是靜態(tài)節(jié)點不會變的比如那句 Hello哪些是動態(tài)節(jié)點依賴 msg 的插值、依賴 show 的 v-if。這一步會打上一堆標(biāo)記比如patchFlag告訴運行時“這個節(jié)點只需要更新文本其他都不用動”。patchFlag是 Vue 3 性能提升的關(guān)鍵設(shè)計之一——編譯時把變化類型算好運行時就不需要再窮舉判斷。第三步代碼生成。編譯器深度遍歷處理過的 AST拼接生成一段 JavaScript 代碼。上面模板會生成簡化后的渲染函數(shù)大致長這樣export function render(_ctx, _cache) { return (_openBlock(), _createElementBlock(div, { class: box }, [ _createElementVNode(p, null, _toDisplayString(_ctx.msg), 1 /* TEXT */), _ctx.show ? (_createElementVNode(span, null, Hello)) : (_createCommentVNode(v-if, true)) ])) }這段代碼里可以清楚看到編譯期決策的影子插值節(jié)點的1 /* TEXT */就是 patchFlag告訴運行時只需要比對文本v-if被編譯成了一個三元表達(dá)式條件不滿足時直接生成注釋節(jié)點占位。2.3 運行時拿到編譯產(chǎn)物之后渲染函數(shù)只是“產(chǎn)出”真正讓頁面出現(xiàn)的是運行時。運行時會調(diào)用渲染函數(shù)得到一個 vnode 描述對象。這個對象不是真實 DOM只是一個輕量級的結(jié)構(gòu)化描述tag 是什么、props 是什么、children 是什么、patchFlag 是什么。然后框架調(diào)用 mount 流程逐個 vnode 創(chuàng)建真實 DOM 掛載到頁面。后續(xù)數(shù)據(jù)變化時組件重新執(zhí)行渲染函數(shù)得到新的 vnode運行時拿到新舊 vnode 做 diff。因為編譯期已經(jīng)把變化的粒度標(biāo)好了diff 不需要遞歸整個樹只需要按 patchFlag 的類型走對應(yīng)的更新邏輯。這就是編譯器與運行時緊密配合的典型范例。我還想特別強調(diào)一點整個編譯過程不一定非要在瀏覽器里發(fā)生。Vue 這樣帶編譯器的構(gòu)建體系在生產(chǎn)構(gòu)建時通過 vite 插件把模板編譯提前到構(gòu)建階段瀏覽器里拿到的已經(jīng)是渲染函數(shù)。這就是為什么官方推薦使用預(yù)編譯——性能更好模板字符串本身也不用附帶一個編譯器代碼包。這也是插件系統(tǒng)能發(fā)揮價值的地方既然編譯發(fā)生在構(gòu)建期那么“編譯到渲染之間”就存在巨大的擴展空間。3. 插件機制三個階段的切入時機3.1 插件到底是個什么東西插件本質(zhì)上就是“在框架特定時間點被調(diào)用的一段代碼”。它能存在的前提是框架預(yù)留了擴展接口。開發(fā)插件前第一個要想清楚的問題不是“我要實現(xiàn)什么功能”而是“框架在哪個時間點允許我介入、我能拿到什么數(shù)據(jù)、能改什么數(shù)據(jù)”。拿 Babel 插件來舉例。Babel 的工作流程分三步解析源碼為 AST - 遍歷 AST 觸發(fā)訪問器 - 生成新代碼。Babel 插件能介入的就是第二步——Babel 在遍歷 AST 時會把你插件里定義的 visitor 拿出來每次經(jīng)過對應(yīng)類型的節(jié)點就調(diào)用一次。你的插件拿到節(jié)點對象可以讀取它、修改它、刪除它、插入新節(jié)點。一個典型的 Babel 插件長這樣module.exports function () { return { visitor: { Identifier(path) { if (path.node.name oldName) { path.node.name newName; } } } }; };這里Identifier就是訪問器名稱每當(dāng) Babel 遍歷到標(biāo)識符節(jié)點時就觸發(fā)。path不僅包含當(dāng)前節(jié)點還包含了到父級節(jié)點、兄弟節(jié)點、作用域信息的引用。這是 AST 插件最核心的操作視角。3.2 編譯期插件在代碼生成前動手前端領(lǐng)域最龐大的插件生態(tài)集中在編譯期。原因很簡單編譯期拿到的 AST 是最結(jié)構(gòu)化、最方便做轉(zhuǎn)換的數(shù)據(jù)形態(tài)什么代碼都能改而且改動會隨構(gòu)建產(chǎn)物固化下來不需要運行時額外開銷。典型代表包括ESLint 規(guī)則插件本質(zhì)是注冊一組 AST 訪問器在遍歷代碼時檢查違規(guī)模式。你寫一個 rule實際上是在寫哪些節(jié)點出現(xiàn)時執(zhí)行哪段校驗邏輯。Babel 插件比如做 JS 壓縮、刪除 console、按需引入組件庫babel-plugin-import 的典型思路就是發(fā)現(xiàn)你用了import { Button } from antd自動替換成import Button from antd/es/button。Vue 模板編譯插件比如自定義v-loading指令你在模板里寫了v-loadingisLoading編譯期插件會遍歷 Element 節(jié)點上的 directives 屬性把它轉(zhuǎn)換成一段調(diào)用resolveDirective的渲染代碼。Markdown 轉(zhuǎn) HTML 的工具比如 markdown-it 插件、VitePress 的 markdown 插件本質(zhì)上也是把 Markdown 解析成語法節(jié)點再在輸出 HTML 前處理這些節(jié)點。我在實際項目里寫過一個小插件用來給團(tuán)隊內(nèi)部組件庫的每個標(biāo)簽自動注入設(shè)計規(guī)范屬性。做法就是在模板 AST 的 Element 節(jié)點上識別組件名前綴然后往 props 對象里追加一條默認(rèn)屬性。整個過程只需要處理 AST 節(jié)點對象不需要碰模板字符串也不會誤傷普通 div。3.3 運行時插件在渲染執(zhí)行時介入和編譯期插件不同運行時插件介入的是 vnode 生成之后的階段。它拿不到 AST拿到的是實例、組件對象、渲染上下文這些運行時產(chǎn)物。拿 Vue 插件生態(tài)來說app.use()注冊的插件本質(zhì)上是一個帶install方法的對象。install被調(diào)用時會收到 app 實例你可以注冊全局組件、指令往app.config.globalProperties上添加全局屬性/方法通過 mixin 往每個組件的生命周期里注入邏輯通過 provide/inject 給整棵樹注入依賴Vue Router 就是典型的運行時插件。它注冊了兩個全局組件RouterView和RouterLink還往全局屬性上掛了$router、$route。頁面路由切換時RouterView組件內(nèi)部根據(jù)當(dāng)前路由記錄匹配組件然后渲染出來。如果給編譯期插件和運行時插件做個對比差異非常明顯維度編譯期插件運行時插件介入時機構(gòu)建階段代碼生成前應(yīng)用運行階段操作對象AST 節(jié)點、編譯上下文組件實例、渲染上下文、vnode性能特征只消耗構(gòu)建時間不影響線上運行每次渲染都可能有調(diào)用開銷代表案例Babel 插件、ESLint 規(guī)則、模板編譯插件Vue Router、Pinia、自定義指令運行時典型限制無法感知運行時動態(tài)數(shù)據(jù)無法感知源代碼級別結(jié)構(gòu)判斷一個功能應(yīng)該做成編譯期插件還是運行時插件我的經(jīng)驗是如果它要修改的是代碼結(jié)構(gòu)、語法形態(tài)且和運行時的具體業(yè)務(wù)數(shù)據(jù)無關(guān)放編譯期如果它必須依賴運行時的全局狀態(tài)、組件實例放運行時。兩個階段也要配合使用的情況并不少見比如 Vue Router 的匹配邏輯在運行時完成但它提供的組件本質(zhì)也需要編譯期發(fā)現(xiàn)別名、解析路徑模式。3.4 寫一個極簡插件實例光說原理太虛我直接給你演示一個編譯期插件的完整寫法。場景團(tuán)隊代碼里有大量直接觸發(fā)alert()的調(diào)用安全規(guī)范要求統(tǒng)一走自定義提示組件。我想在編譯期把所有alert(...)調(diào)用替換成this.$toast(...)。用 Babel 插件實現(xiàn)module.exports function ({ types: t }) { return { name: replace-alert-to-toast, visitor: { CallExpression(path) { const callee path.node.callee; // 只處理 alert(...) 調(diào)用 if (!isAlertReference(callee)) return; const args path.node.arguments.map(arg t.isStringLiteral(arg) ? arg : t.callExpression( t.identifier(String), [arg] ) ); // 替換成 this.$toast(...) path.replaceWith( t.callExpression( t.memberExpression( t.thisExpression(), t.identifier($toast) ), args ) ); } } }; }; function isAlertReference(callee) { // 只匹配 id 為 alert 且不是屬性調(diào)用如 window.alert return ( t.isIdentifier(callee, { name: alert }) ); }在 Babel 配置里加載這個插件然后發(fā)現(xiàn)代碼里的alert(保存成功)構(gòu)建后全部變成了this.$toast(保存成功)。這個改動不需要業(yè)務(wù)開發(fā)者一個個去手動改所有代碼構(gòu)建時自動完成這就是編譯期插件的威力。類似思路還能做很多事自動加埋點、自動清除 debug 日志、自動注入國際化函數(shù)。4. 視圖替換從數(shù)據(jù)到界面的動態(tài)切換4.1 視圖替換的四種不同層次“視圖替換”是一個容易被誤解的詞。有人以為是路由切換有人以為是 Tab 切換有人以為是彈窗關(guān)閉。其實在實際項目中視圖替換至少有四個層次每個層次的原理和坑都不一樣。第一層是最基礎(chǔ)的條件渲染。用v-if切換一個區(qū)塊的顯示隱藏。第二層是組件級替換同樣的掛載點根據(jù)狀態(tài)渲染不同的組件。第三層是路由級替換整個頁面組件被替換。第四層是自定義渲染器級替換你直接換掉整個渲染目標(biāo)比如原來渲染到 DOM現(xiàn)在渲染到 Canvas、WebGL 甚至自定義數(shù)據(jù)協(xié)議。理解這四層對處理實際問題特別有幫助因為報錯信息往往只會告訴你“哪里掛了”不會告訴你“是哪個層次的替換邏輯出問題了”。4.2 v-if 與 v-show本質(zhì)上是節(jié)點樹的增刪與樣式切換先看最基礎(chǔ)的視圖替換。v-if和v-show是很多人從入門就在用的指令但未必清楚兩者背后完全不同的實現(xiàn)路徑。編譯 Vue 模板時v-if會被編譯成條件表達(dá)式前面代碼示例里已經(jīng)見過。運行時條件為 true 就創(chuàng)建真實節(jié)點并插入 DOM條件為 false 就創(chuàng)建或保留一個注釋節(jié)點做占位并在 diff 時刪除真實節(jié)點。視圖的替換在這個場景里是真實的 DOM 節(jié)點創(chuàng)建與銷毀。v-show則不同。它不管條件真假節(jié)點始終渲染只是通過內(nèi)聯(lián)樣式控制display來切換可見性。視圖在頁面上“變了”但 DOM 里元素一直在。這套做法的優(yōu)點是切換開銷小缺點是首屏要渲染本來不該出現(xiàn)的 DOM。選型建議很簡單如果切換頻率高、過度動畫不需要、節(jié)點創(chuàng)建成本高用 v-show如果條件變化不頻繁、或初始條件幾乎不成立用 v-if 省掉多余的 DOM。很多人一上來就“追求性能”無腦用 v-if其實切換頻繁的 Tab 面板用 v-show 往往體驗更好。4.3 動態(tài)組件與路由視圖掛載點不變組件變當(dāng)我們說“視圖替換”時更常指的是“同一個掛載位置渲染不同的組件”。在 Vue 里是component :iscurrentComponent /在 React 里類似的是條件返回不同組件。原理上是這樣的component組件會接收is屬性的值這個值可以是一個組件對象也可以是一個注冊過的組件名。渲染時當(dāng)前的 vnode 的 tag 就是這個動態(tài)組件diff 時發(fā)現(xiàn) tag 變了框架會銷毀舊的組件實例創(chuàng)建新的組件實例走完整的 init - mount 流程。這里有個非常隱蔽的坑值得單獨拿出來說如果你切換的是同一個組件類型但是不同的 keyVue 是如何處理的。比如component :iscurrentView :keyviewKey /當(dāng)key改變時框架會強制認(rèn)為這是“不同的組件”即使is的類型沒變也會銷毀重建。這是一個很好用的技巧比如表單重置只要改變 key組件內(nèi)所有本地狀態(tài)都會被清空不需要手動調(diào)重置方法。路由視圖RouterView本質(zhì)上是動態(tài)組件的進(jìn)階封裝。它根據(jù)當(dāng)前 URL 匹配到的路由記錄來決定渲染哪個頁面組件。和動態(tài)組件不同的是RouterView 還負(fù)責(zé)把 URL 參數(shù)注入 props通過route對象并且配合嵌套路由處理多級視圖的渲染。切換路由時如果沒有keep-alive老的頁面組件實例會被銷毀所有本地數(shù)據(jù)丟失。加了keep-alive之后組件實例會被緩存deactivated/activated 生命周期就會介入。4.4 自定義渲染器直接把渲染目標(biāo)換掉第四層視圖替換少有人提但對插件開發(fā)者來說是極具價值的。Vue 3 的createRenderer把渲染邏輯抽象成與平臺無關(guān)的模塊默認(rèn)傳的是 DOM 操作的 APIinsert、patchProp、remove等但你可以傳入自己的 API讓同樣的組件邏輯渲染到完全不同的目標(biāo)上。這是很多跨端方案的核心原理。比如小程序端渲染目標(biāo)不是 DOM而是小程序的自定義組件樹Canvas 渲染引擎會把 vnode 對應(yīng)到畫布上的圖形對象甚至有人把 Vue 渲染到終端命令行界面的。我簡單描述一個極簡自定義渲染器的骨架const { createRenderer } require(vue); const renderer createRenderer({ createElement(type) { // 返回自定義節(jié)點對象比如 canvas 圖形對象 return new CanvasNode(type); }, insert(child, parent, anchor) { // 把子節(jié)點掛到父節(jié)點上 parent.append(child); }, patchProp(el, key, prevValue, nextValue) { // 更新自定義節(jié)點的屬性 el[key] nextValue; }, remove(el) { el.remove(); } });一旦走到了自定義渲染器這一層視圖替換就不再只是組件切換而是你可以把同一套業(yè)務(wù)組件邏輯投射到任意“長得像 DOM”的目標(biāo)結(jié)構(gòu)上。這能力對做可視化大屏、游戲 UI、跨端框架的人來說相當(dāng)于給了一套完整可復(fù)用的渲染基礎(chǔ)設(shè)施。5. 常見問題與排查技巧實錄5.1 渲染層報錯Cannot read properties of undefined熱詞里有一條典型報錯[渲染層錯誤] uncaught typeerror: cannot read properties of undefined (reading ...)。這種報錯很讓人抓狂因為它往往不告訴你具體是哪個變量出了問題只告訴你渲染層某處訪問了 undefined 的屬性。根據(jù)我個人經(jīng)驗這類報錯最常見的根源有三個第一個是在模板里訪問了尚未初始化的數(shù)據(jù)。比如接口返回前組件就先渲染了data里的對象還是undefined模板里寫了user.name。解決辦法是模板里做空值兜底或者初始化數(shù)據(jù)時給個默認(rèn)值。第二個是 v-for 的遍歷對象本身是 undefined。和上面同理v-foritem in list中l(wèi)ist如果晚于首次渲染才被賦值就會炸。第三個是編譯插件/模板插件導(dǎo)致的字段缺失。如果你啟用了自定義編譯插件插件在轉(zhuǎn)換 AST 時可能生成了引用某字段但沒聲明的代碼。這種錯誤比較隱蔽因為報錯棧指向的是一段編譯后的代碼不是你寫的源碼。排查思路是先關(guān)掉可疑插件跑一遍如果正常了再用 source map 定位到編譯后的具體位置反查原模板或原代碼。5.2 插件不生效AST 版本和遍歷時機的問題插件不生效比報錯還難排查因為程序沒告訴你哪里不對。整理幾個我踩過的坑。第一個是插件返回的 visitor 名字寫錯了。Babel 和 ESLint 的 visitor 是基于 AST 節(jié)點類型命名的CallExpression、Identifier、VariableDeclaration大小寫和拼寫必須嚴(yán)格一致。拼錯一個字符插件就默默地什么都不做。第二個是插件順序問題。多個插件操作同一個節(jié)點時后執(zhí)行的插件看到的是前一個插件改完的結(jié)果。如果你的插件依賴某個前序插件轉(zhuǎn)換完成的產(chǎn)物但又排在它前面自然失效。比如你寫了一個 Babel 插件想把import { A } from pkg轉(zhuǎn)換成按需加載但如果另一個插件先一步把 import 語法轉(zhuǎn)換成了require你的插件可能匹配不到ImportDeclaration節(jié)點了。第三個是 AST 結(jié)構(gòu)隨工具版本變化。Babel 7 到 8、ESLint 8 到 9AST 節(jié)點字段和訪問器結(jié)構(gòu)都有調(diào)整。一個為舊版本寫的插件在新版本里可能讀取的字段根本不存在。升級依賴后插件突然全部失效優(yōu)先懷疑這個原因去 changelog 里搜 visitor and AST breaking changes。到這里我順便分享一個更通用的排查技巧無論是編譯期插件還是運行時插件先做一個最小復(fù)現(xiàn)。新建一個只包含報錯特征的最簡文件關(guān)掉一半插件跑一遍再關(guān)掉另一半用二分法快速縮小問題范圍。這個辦法在復(fù)雜項目里比鉆牛角尖看代碼高效太多。5.3 視圖替換不生效key、緩存和生命周期視圖替換最常見的問題歸結(jié)起來就三類替換沒發(fā)生、替換太頻繁、替換后狀態(tài)丟失。替換沒發(fā)生的常見原因是 key 沒變。Vue 和 React 的 diff 算法都以 key 作為復(fù)用的依據(jù)。如果你想強制某個組件重新渲染比如下次切換回來自動刷新數(shù)據(jù)但 key 一直沒變框架會判斷為同類組件直接復(fù)用實例不走銷毀重建狀態(tài)不會重置。解法就是給組件一個和業(yè)務(wù)狀態(tài)綁定的 key。替換太頻繁的坑通常出現(xiàn)在動態(tài)組件和路由視圖上。比如你的動態(tài)組件綁定的是一個每次渲染都會創(chuàng)建新對象引用的計算屬性每次數(shù)據(jù)變更都導(dǎo)致is變成一個“看起來相同但引用不同”的組件框架就會把它當(dāng)成不同組件重建實例。用 console.log 打印組件實例或用 vnode 的 type 檢查一下能快速確認(rèn)是不是這個原因。替換后狀態(tài)丟失則是 keep-alive 使用不當(dāng)。加了keep-alive之后組件切換不會銷毀但被緩存的組件如果內(nèi)部依賴定時器、WebSocket、全局事件監(jiān)聽恢復(fù)時可能因為 deactivated/activated 沒被正確利用出現(xiàn)數(shù)據(jù)過期或事件重復(fù)綁定的問題。我的習(xí)慣是凡是被 keep-alive 緩存的組件所有全局事件監(jiān)聽和定時器必須在 deactivated 里清除在 activated 里重新注冊。這幾種問題我都做過整理可以直接當(dāng)速查表用現(xiàn)象可能原因排查方向解決方案切換組件后內(nèi)部狀態(tài)沒重置key 未變化檢查組件綁定的 key手動綁定業(yè)務(wù)狀態(tài) key組件被頻繁重建is每次引用不同打印組件 type 是否相同將組件對象緩存在變量中路由切換后頁面數(shù)據(jù)丟失無緩存或緩存策略不對檢查是否使用了 keep-alive按需加 keep-alive 并處理激活邏輯自定義插件生成了 undefined 字段插件編譯產(chǎn)物缺聲明關(guān)閉插件跑一遍對照修改插件轉(zhuǎn)換邏輯或升級適配ESLint 規(guī)則不觸發(fā)visitor 名稱拼寫錯誤檢查節(jié)點類型名對照 AST explorer 修正名稱5.4 調(diào)試 AST 與渲染鏈路的實用工具排查這些問題時好用的工具能省一半時間。我常用的工具清單如下AST Explorerastexplorer.net在線查看各種語言的 AST 結(jié)構(gòu)。左邊寫代碼右邊實時顯示 AST 樹支持切換 parserbabel、espree、typescript、vue 模板編譯器是調(diào)試插件最順手的工具。Vue Template Explorertemplate-explorer.vuejs.org專門看 Vue 模板編譯輸出的渲染函數(shù)。左邊寫模板右邊顯示編譯后的代碼和 patchFlag理解模板編譯產(chǎn)物時非常直觀。source-map 支持確保構(gòu)建工具開啟 source map報錯時能定位到源碼而不是編譯后的渲染函數(shù)代碼。vite 插件的 dev server hook寫 Vite 插件時直接在transform鉤子里 console.log 當(dāng)前模塊的代碼可以實時看到構(gòu)建時各個模塊經(jīng)過插件后的產(chǎn)物。調(diào)試 AST 插件有個通用心法先打印后修改。在 visitor 里一開始就 console.log 當(dāng)前節(jié)點的 type 和關(guān)鍵字段確認(rèn)遍歷到了你想要的節(jié)點再去動修改邏輯。很多人插件不生效就是因為對節(jié)點結(jié)構(gòu)認(rèn)知有偏差直接照著自己想象的字段去寫代碼最后在讀一個不存在的屬性。6. 從“會寫插件”到“設(shè)計插件”6.1 插件 API 的設(shè)計原則如果你已經(jīng)能熟練寫插件下一步就是設(shè)計插件。兩者區(qū)別很大。給自己項目寫插件怎么快怎么來給別人用的插件第一原則是“別讓我意外”。我總結(jié)了三條對插件設(shè)計最重要的經(jīng)驗。第一盡量不修改用戶代碼的默認(rèn)行為。插件的功能應(yīng)該是“新增”而不是“改變”。比如我前文提到的把 alert 替換成 $toast這種設(shè)計就需要提供顯式開關(guān)而不是默認(rèn)開啟。用戶引入插件后發(fā)現(xiàn)自己線上行為變了是最可怕的體驗。第二提供清晰的錯誤提示。插件出錯時給一句可讀的提示比直接拋一個對象、讓用戶自己看堆棧強得多。插件是運行在用戶構(gòu)建鏈路上的一個報錯可能阻塞整個團(tuán)隊開發(fā)錯誤信息應(yīng)該盡可能指出是哪段代碼、哪個模板、哪個配置引起的。第三插件要有最小可用實現(xiàn)。不要一開始就覆蓋幾十種邊界情況先把核心場景跑通然后在真實項目中不斷迭代。一個只有幾百行代碼但穩(wěn)定可靠的插件遠(yuǎn)好過一個堆滿功能但經(jīng)常出事的重型插件。6.2 編譯轉(zhuǎn)換的威力與邊界寫了幾年 AST 插件之后我越來越覺得“編譯轉(zhuǎn)換”是一種類似元編程的能力。你寫的不是給用戶用的業(yè)務(wù)代碼而是能生產(chǎn)業(yè)務(wù)代碼的程序。這種能力的力量很強但邊界也很清楚它是靜態(tài)的。編譯期能看到的只有代碼本身看不到運行時的數(shù)據(jù)。你想在編譯期根據(jù)用戶登錄狀態(tài)做渲染分支做不到因為登錄狀態(tài)是運行時才有。你只能生成“檢查登錄狀態(tài)的代碼”不能直接生成“登錄狀態(tài)的最終結(jié)果”。明白這個邊界就不容易寫出過度設(shè)計的插件。反過來運行時也無法獲取源碼的結(jié)構(gòu)化信息。Vue 的運行時插件要分析組件的 props 來源、export 的變量結(jié)構(gòu)往往很吃力因為運行時組件對象里可能已經(jīng)丟失了源碼的很多細(xì)節(jié)。所以在設(shè)計任何一次“代碼轉(zhuǎn)換”時先問一句這個轉(zhuǎn)換應(yīng)該發(fā)生在哪個階段這個判斷本身比寫代碼困難得多也重要得多。我個人在實際操作中的體會是AST 相關(guān)的問題80% 都能靠 AST Explorer 和 console.log 節(jié)點對象解決剩下 20% 里又有一大半是版本不匹配導(dǎo)致的。真正復(fù)雜的是“想清楚要在哪個階段、哪個節(jié)點、做什么樣的轉(zhuǎn)換”這個設(shè)計決策決定了插件是幫助開發(fā)者還是添亂。如果你剛開始接觸這塊建議從寫一個能自動刪除 console 的 Babel 插件練手跑通之后再去改造自己的開發(fā)流程里那些反復(fù)手動的環(huán)節(jié)會讓你對整條鏈路有完全不一樣的感受。