老讀者應(yīng)該清楚我一直對編譯器前端的“黑盒”很感興趣。這是系列第二章專門聊從AST到渲染這條鏈路——也就是模板、源碼到底怎么變成界面上的視圖以及我們作為插件開發(fā)者、日常工具使用者能在哪些環(huán)節(jié)做手腳、替換默認(rèn)視圖。核心關(guān)鍵詞就是三個(gè)AST、渲染、插件再加一個(gè)動詞“視圖替換”。我先說結(jié)論很多人寫業(yè)務(wù)代碼寫了幾年對Vue/React的模板編譯還是一臉懵遇到視圖不更新、插件不生效、自定義指令失效這類問題只能靠猜。實(shí)際上只要把“源碼字符串 - AST - 轉(zhuǎn)換 - 渲染函數(shù) - VNode - 真實(shí)DOM”這條鏈路理清楚絕大多數(shù)問題都能從原理上定位。這篇我把每個(gè)環(huán)節(jié)拆開講穿插可復(fù)現(xiàn)的代碼和踩坑記錄適合前端開發(fā)者、編譯器愛好者、寫構(gòu)建工具的工程效率團(tuán)隊(duì)參考。放心我不會把文章寫成教科書能動手的地方盡量帶你們動手。1. 鏈路全景從源碼到屏幕上到底經(jīng)過了幾站1.1 為什么需要AST這個(gè)中間站先回答一個(gè)很多人問過我的問題編譯器為什么不直接拿源代碼字符串去生成目標(biāo)代碼非要繞一圈搞一棵樹出來因?yàn)樵创a在計(jì)算機(jī)眼里就是一串純文本純文本是拍平的一維數(shù)據(jù)但代碼里的嵌套關(guān)系是立體的。你要讓編譯器“理解”divspan{{ name }}/span/div里誰是誰的父節(jié)點(diǎn)、哪里是表達(dá)式、哪里是靜態(tài)文本光靠正則和字符串匹配寫出來的東西脆弱得離譜。ASTAbstract Syntax Tree抽象語法樹就是把一維字符串變成一棵結(jié)構(gòu)化的樹每個(gè)節(jié)點(diǎn)帶自己的類型、屬性、子節(jié)點(diǎn)列表后續(xù)所有處理都圍繞這棵樹展開。打個(gè)生活比方你拿到一篇文章的純文本機(jī)器很難直接判斷“標(biāo)題3”是“標(biāo)題2”的子標(biāo)題還是下一章開頭。但如果你先把文章斷句、分段落、標(biāo)好層級后續(xù)排版、生成目錄、提取摘要就都有了結(jié)構(gòu)依據(jù)。AST就是代碼的“結(jié)構(gòu)化文檔”它保留了語法骨架丟掉了純格式信息比如縮進(jìn)、多余空格只在需要定位時(shí)通過位置字段找回原文。1.2 渲染鏈路里的三段變換從源碼到屏幕上的像素前端領(lǐng)域可以粗暴地分成三段編譯期、執(zhí)行期、更新期。編譯期負(fù)責(zé)把模板或源碼變成可執(zhí)行的東西。以Vue 3為例模板字符串先進(jìn)parse變成AST再走transform做靜態(tài)標(biāo)記、指令轉(zhuǎn)換、優(yōu)化最后經(jīng)過codegen生成render函數(shù)字符串。Babel處理JS代碼也是同一套思路源碼 - token - AST - 插件轉(zhuǎn)換 - 新AST - 生成目標(biāo)代碼。整個(gè)編譯期的核心是“AST的生成與變形”。執(zhí)行期則把編譯產(chǎn)物真正跑起來。render函數(shù)執(zhí)行后返回的是VNode虛擬節(jié)點(diǎn)樹渲染器拿到這棵VNode樹mount階段創(chuàng)建真實(shí)DOM掛到頁面上。注意這里說的渲染不是圖形學(xué)里的光柵化而是“把數(shù)據(jù)描述變成可交互視圖”的完整過程。如果你做過Three.js、OpenGL那類圖形渲染千萬別把兩個(gè)概念混在一起前端的虛擬DOM渲染重點(diǎn)在結(jié)構(gòu)化描述和增量更新不是逐像素繪制。更新期是用戶體驗(yàn)的關(guān)鍵。數(shù)據(jù)變化后響應(yīng)式系統(tǒng)觸發(fā)依賴render函數(shù)重新執(zhí)行生成新的VNode樹再經(jīng)過diff和patch更新真實(shí)DOM。這一階段的“視圖替換”最劇烈也最容易出問題后面我會單獨(dú)展開。插件可以插在哪理論上每一站都能插。Babel插件運(yùn)行在AST遍歷階段Vue compiler插件運(yùn)行在transform階段Vue運(yùn)行時(shí)插件比如app.use(...)安裝的插件運(yùn)行在組件初始化、渲染期間。甚至視圖替換也有多種姿勢編譯期把模板里的組件A替換成組件B運(yùn)行時(shí)用動態(tài)組件切換渲染函數(shù)里手動返回不同VNode插件全局覆蓋某類組件的render。理解了鏈路你就等于拿到了一張地圖插件只是地圖上的快捷方式。2. 從模板到ASTparse階段到底做了什么2.1 模板語法到AST節(jié)點(diǎn)的映射我們直接拿Vue 3的vue/compiler-core跑一個(gè)最小例子。裝好依賴后寫一段腳本const { baseParse } require(vue/compiler-core) const ast baseParse(div classbox{{ name }}/div) console.log(JSON.stringify(ast, null, 2))輸出能看到一棵完整的AST樹我這里簡化出核心節(jié)點(diǎn){ type: 0, children: [ { type: 1, tag: div, props: [ { type: 6, name: class, value: { content: box } } ], children: [ { type: 5, content: { type: 4, content: name } } ] } ] }這里type是節(jié)點(diǎn)類型0是根節(jié)點(diǎn)1是元素節(jié)點(diǎn)5是插值表達(dá)式節(jié)點(diǎn)4是簡單表達(dá)式節(jié)點(diǎn)6是屬性節(jié)點(diǎn)。第一次看這些數(shù)字可能覺得抽象但你要抓住的規(guī)律很簡單樹里每個(gè)節(jié)點(diǎn)都在描述源碼里的一個(gè)語法單元“div”是元素classbox是屬性{{ name }}是動態(tài)表達(dá)式。parse階段要做的事情說白了就是把模板字符串拆成token再按標(biāo)簽嵌套規(guī)則組裝成這顆樹。切片字符串時(shí)插值{{ }}要單獨(dú)切出來屬性名和屬性值要配對自閉合標(biāo)簽要特殊處理。做完這些編譯器才算真正“看懂”了你的模板。2.2 一個(gè)極簡parser的解析思路我不是讓每個(gè)人都去手寫一個(gè)編譯器但理解parse的核心思路對排查問題幫助很大。一個(gè)最樸素的模板parser可以分成tokenizer和parser兩層。tokenizer負(fù)責(zé)把字符串切成token流。比如div classbox{{ name }}/div會切出div、classbox、、{{ name }}、/div這一串。每個(gè)token知道自己是開始標(biāo)簽、結(jié)束標(biāo)簽、文本還是屬性。parser層用棧維護(hù)父子關(guān)系遇到開始標(biāo)簽創(chuàng)建一個(gè)元素節(jié)點(diǎn)并壓入棧頂后續(xù)的文本、插值節(jié)點(diǎn)都掛到棧頂節(jié)點(diǎn)的children里遇到結(jié)束標(biāo)簽彈出棧頂回到父節(jié)點(diǎn)處理?？s進(jìn)在模板語法里不是語義的一部分所以解析器直接忽略空白處理注釋節(jié)點(diǎn)是否保留取決于編譯配置。對你來說這個(gè)思路的實(shí)際價(jià)值是當(dāng)某個(gè)模板片段被編譯器解析得不符合預(yù)期時(shí)你能快速猜出“是token切錯(cuò)了還是棧的出入順序出了問題”而不是對著報(bào)錯(cuò)信息干瞪眼?，F(xiàn)在的編譯器都成熟穩(wěn)定但理解原理能幫你判斷到底該懷疑模板寫法、編譯器bug還是插件改動。2.3 解析器插件縫在哪Babel插件就是在AST遍歷程中動手腳的。比如你要把代碼里的$t(hello)替換成i18n.t(hello)本質(zhì)就是遍歷AST找到CallExpression節(jié)點(diǎn)修改它的callee。插件不同實(shí)現(xiàn)方式obs起來是visitor對象module.exports function i18nPlugin(babel) { const { types: t } babel return { visitor: { CallExpression(path) { if (t.isIdentifier(path.node.callee, { name: $t })) { path.node.callee t.memberExpression( t.identifier(i18n), t.identifier(t) ) path.node.arguments path.node.arguments.map(arg t.stringLiteral(arg.value) ) } } } } }Vue的編譯器插件縫在transform階段比如自定義一個(gè)nodeTransform能在AST節(jié)點(diǎn)上改標(biāo)簽名。我們團(tuán)隊(duì)內(nèi)部做過一個(gè)“廢棄組件自動替換”插件模板里寫DeprecatedTag編譯期直接把它替換成新組件NewTag還自動補(bǔ)上遷移屬性。這種需求用AST節(jié)點(diǎn)替換做比在業(yè)務(wù)代碼里寫正則可靠一百倍因?yàn)锳ST是結(jié)構(gòu)化的不會誤傷字符串內(nèi)容。3. transform與codegenAST變身可執(zhí)行渲染函數(shù)3.1 transform階段做了哪些優(yōu)化AST生成后不能直接拿去跑得先過一次transform把模板里的指令變成邏輯判斷把動態(tài)節(jié)點(diǎn)標(biāo)記出來。Vue 3的transform主要有兩個(gè)任務(wù)指令降級和靜態(tài)優(yōu)化。指令降級很好理解。v-if會被轉(zhuǎn)換成三元表達(dá)式v-for會被轉(zhuǎn)換成循環(huán)v-on會被轉(zhuǎn)換成事件綁定代碼。你模板里寫的聲明式語法編譯后全部變成命令式的JavaScript邏輯。靜態(tài)優(yōu)化的重點(diǎn)則是給節(jié)點(diǎn)打PatchFlag。編譯器分析出哪些節(jié)點(diǎn)是純靜態(tài)的不會隨數(shù)據(jù)變化哪些節(jié)點(diǎn)的文本是動態(tài)的哪些屬性可能變化然后給動態(tài)節(jié)點(diǎn)打上標(biāo)記。diff階段拿到這個(gè)標(biāo)記只需要精確更新對應(yīng)的部分不需要整棵樹重新對比。這也是Vue 3性能比Vue 2提升的關(guān)鍵之一。舉個(gè)例子模板div classbox{{ name }}/div編譯出來的render函數(shù)末尾會帶1 /* TEXT */這個(gè)1就是PatchFlag代表“子元素里有動態(tài)文本”。patch時(shí)看到這個(gè)標(biāo)記就知道只需要更新文本內(nèi)容class和結(jié)構(gòu)都不用碰。3.2 codegen遞歸拼出渲染函數(shù)字符串transform之后AST進(jìn)入codegen階段。這個(gè)階段的核心操作是遞歸遍歷AST拼出一段JavaScript代碼。以上面的模板為例編譯產(chǎn)物大概是這樣的import { createElementVNode as _createElementVNode, toDisplayString as _toDisplayString } from vue export function render(_ctx, _cache) { return _createElementVNode( div, { class: box }, _toDisplayString(_ctx.name), 1 /* TEXT */ ) }看到這段代碼不要慌。_createElementVNode是運(yùn)行時(shí)的輔助函數(shù)專門用來創(chuàng)建虛擬節(jié)點(diǎn)_ctx是當(dāng)前組件實(shí)例上下文模板里寫name編譯之后就變成_ctx.name_toDisplayString負(fù)責(zé)把變量變成適合展示的字符串。為什么編譯器要把AST還原成代碼字符串而不是直接生成一個(gè)VNode對象關(guān)鍵在于render函數(shù)是一個(gè)可執(zhí)行、可序列化、可跨環(huán)境的描述。它不直接操作DOM只負(fù)責(zé)“描述這次視圖應(yīng)該長什么樣”具體怎么創(chuàng)建DOM由運(yùn)行時(shí)渲染器去干。這樣的好處是同一套編譯產(chǎn)物可以跑在瀏覽器、小程序、SSR服務(wù)端只要各自環(huán)境提供對應(yīng)的輔助函數(shù)。3.3 拼接代碼相比直接操作的隱藏優(yōu)勢很多人第一次看到codegen輸出會覺得多此一舉明明已經(jīng)解析出AST了遍歷AST直接創(chuàng)建DOM不就行了不行。第一AST是編譯期的東西它跟具體運(yùn)行環(huán)境無關(guān)。如果把AST直接綁定到DOM操作那模板就永遠(yuǎn)只能跑在瀏覽器里換個(gè)平臺全廢。codegen輸出代碼字符串等于把“視圖描述”和“平臺實(shí)現(xiàn)”解耦了。第二生成的render函數(shù)可以再次被編譯、緩存、按需加載工程上靈活得多。第三從性能角度講代碼字符串比AST更好做tree-shaking編譯器能精確分析出用到了哪幾個(gè)輔助函數(shù)比如_createElementVNode、_toDisplayString打包時(shí)按需引入減小產(chǎn)物體積。實(shí)測下來這種設(shè)計(jì)在處理跨端需求時(shí)特別香。我們之前做過一個(gè)項(xiàng)目同一個(gè)模板在Web端和小程序端分別編譯只是codegen的目標(biāo)輔助函數(shù)不同業(yè)務(wù)代碼完全不用改。4. 渲染器與視圖替換插件的舞臺4.1 從VNode到真實(shí)DOM的patch流程render函數(shù)執(zhí)行后返回的是一棵VNode樹它只是普通JavaScript對象描述“界面應(yīng)該長什么樣”。真正把它變成頁面上的真實(shí)DOM靠的是渲染器。首次渲染走mount流程渲染器看到VNode的type是字符串div就document.createElement(div)設(shè)置屬性然后把子節(jié)點(diǎn)遞歸創(chuàng)建出來掛上去。更新走patch流程新舊兩棵VNode樹做對比如果節(jié)點(diǎn)類型不同直接替換如果類型相同對比屬性和子節(jié)點(diǎn)盡量復(fù)用已有DOM元素。這塊設(shè)計(jì)得很聰明的地方在于VNode樹之間的差異計(jì)算不依賴真實(shí)DOM操作。真實(shí)DOM的操作成本高js對象的對比成本低把一個(gè)高成本操作變?yōu)榈统杀颈容^精準(zhǔn)更新性能自然就上來了。PatchFlag在這里派上大用場帶TEXT標(biāo)記的節(jié)點(diǎn)只需要更新textContent帶CLASS標(biāo)記的節(jié)點(diǎn)只需要更新className。4.2 視圖替換的幾種姿勢與實(shí)戰(zhàn)選擇“視圖替換”聽起來很高大上其實(shí)日常開發(fā)里你已經(jīng)用過很多次了。我?guī)湍阏硪幌聫淖钶p量到最重度的替換方式v-if/v-show真正的刪除節(jié)點(diǎn)和僅切換display屬于結(jié)構(gòu)級替換。動態(tài)組件component :isxxx /切換時(shí)渲染不同組件屬于組件級替換。插槽父組件向子組件注入視圖內(nèi)容子組件只負(fù)責(zé)搭框架屬于內(nèi)容級替換。渲染函數(shù)覆蓋在組件里重寫render返回完全不同的VNode屬于邏輯級替換。插件全局替換第三方插件通過app.component注冊同名組件、用mixin改寫生命周期悄無聲息換掉默認(rèn)視圖屬于框架級替換。我實(shí)際做過一個(gè)A/B測試方案運(yùn)營后臺配置一個(gè)實(shí)驗(yàn)組前端插件根據(jù)配置在組件初始化時(shí)把首頁首屏的render替換成另一套模板的VNode樹。這種需求用全局插件做最合適頁面代碼零侵入上線回滾只改配置即可。4.3 數(shù)據(jù)驅(qū)動視圖替換的觸發(fā)鏈視圖不會自己變它靠的是響應(yīng)式系統(tǒng)觸發(fā)。簡化鏈路如下數(shù)據(jù)變化setter觸發(fā)- 響應(yīng)式系統(tǒng)通知依賴render函數(shù)- 渲染函數(shù)重新執(zhí)行 - 生成新VNode樹 - patch對比并更新DOM。這一步很多人會有疑問為什么改了數(shù)據(jù)頁面就更新了因?yàn)閞ender函數(shù)在初次執(zhí)行時(shí)凡是用到的響應(yīng)式數(shù)據(jù)都會被收集為這個(gè)“渲染副作用”的依賴。數(shù)據(jù)一旦變化副作用重新執(zhí)行新VNode就誕生了后續(xù)走patch流程。理解這個(gè)觸發(fā)鏈你就能解釋一些經(jīng)典坑。比如舊版Vue里直接通過索引改數(shù)組元素、或者給對象新增屬性視圖不更新本質(zhì)是因?yàn)檫@些操作沒有觸發(fā)setter依賴根本沒被通知。Vue 3用Proxy解決了大部分問題但如果你替換的是整個(gè)響應(yīng)式對象、或者對Map/Set做某些操作邊界情況還是得心里有數(shù)。視圖替換的最后一步一定是patch如果前面某一步斷了界面自然紋絲不動。5. 插件開發(fā)實(shí)戰(zhàn)在AST和渲染中間動手腳5.1 寫一個(gè)Babel插件轉(zhuǎn)換AST實(shí)現(xiàn)語法糖替換我先帶你走一個(gè)最簡單的Babel插件。目標(biāo)是把代碼里的$t(hello)編譯成i18n.t(hello)這個(gè)用法在內(nèi)部老項(xiàng)目遷移時(shí)很常見。module.exports function i18nPlugin(babel) { const { types: t } babel return { name: i18n-plugin, visitor: { CallExpression(path) { if (t.isIdentifier(path.node.callee, { name: $t })) { const [arg] path.node.arguments const callee t.memberExpression( t.identifier(i18n), t.identifier(t) ) path.replaceWith(t.callExpression(callee, [t.stringLiteral(arg.value)])) } } } } }測試方式很簡單const babel require(babel/core) const result babel.transformSync(const text $t(hello), { plugins: [i18nPlugin] }) console.log(result.code) // const text i18n.t(hello);這里有幾個(gè)容易踩的坑。第一改完node之后如果調(diào)用的是path.node賦值有時(shí)候不會觸發(fā)重新解析最好用replaceWith或insertBefore這類顯式方法。第二如果babel插件的visitor里修改了節(jié)點(diǎn)結(jié)構(gòu)必須注意作用域問題新增的標(biāo)識符可能與上下文沖突穩(wěn)妥做法是用path.scope.generateUidIdentifier生成唯一名字。5.2 寫一個(gè)Vue插件全局覆蓋默認(rèn)視圖Vue插件的作用面比Babel插件更偏向運(yùn)行時(shí)。app.use(plugin)執(zhí)行時(shí)調(diào)用install(app, options)你在里面能拿到整個(gè)應(yīng)用實(shí)例。下面這個(gè)插件實(shí)現(xiàn)了一個(gè)“視圖映射表”功能安裝插件時(shí)傳入viewMap指定某個(gè)組件名用哪個(gè)新組件替換渲染視圖。export default { install(app, { viewMap {} } {}) { app.mixin({ created() { const name this.$options.name if (name viewMap[name]) { const originalRender this.$options.render this.$options.render function (ctx) { const vnode originalRender.call(this, ctx) return viewMap[name].call(this, ctx) || vnode } } } }) } }用的時(shí)候app.use(ViewReplacePlugin, { viewMap: { // 把首頁組件替換成活動版首頁 HomePage: (ctx) h(ActivityHomePage) } })我的真實(shí)感受是這種方案適合做“全局的臨時(shí)放量或活動切換”業(yè)務(wù)代碼完全不用感知。但要注意替換render時(shí)如果有舊組件的狀態(tài)和事件綁定替換前先保存舊render替換失敗要能回退而且視圖替換后組件的生命周期不會重走依賴原來的created、mounted做初始化的邏輯要格外小心。5.3 寫一個(gè)編譯期插件按條件替換AST節(jié)點(diǎn)運(yùn)行時(shí)替換有成本畢竟新組件還是要走初始化、掛載。有些場景更適合在編譯期就換掉比如多端小程序。模板里寫LazyImage編譯到Web端替換成ImgFallback編譯到小程序端替換成Image。Vue 3提供了vue/compiler-core的transform接口const { transform, generate } require(vue/compiler-core) function replaceComponent(node, context) { if (node.type 1 node.tag LazyImage) { node.tag Image node.props.push({ type: 6, name: mode, value: { content: aspectFill } }) } } const ast baseParse(viewLazyImage srca.png //view) transform(ast, { nodeTransforms: [replaceComponent] }) const { code } generate(ast) console.log(code)編譯期替換的好處是運(yùn)行時(shí)代碼干凈沒有插件介入的額外開銷。壞處是調(diào)試鏈路變長一旦AST處理出錯(cuò)編譯產(chǎn)物可能帶著半截結(jié)構(gòu)直接報(bào)錯(cuò)。我的建議是編譯期插件要配套一個(gè)“AST快照打印”的調(diào)試工具把transform前后的AST分別dump出來對比別等到運(yùn)行時(shí)報(bào)錯(cuò)才去猜。5.4 一個(gè)心得自定義transform的執(zhí)行順序要確認(rèn)如果同時(shí)用了多個(gè)自定義transform順序不是無所謂的。Vue編譯器的nodeTransforms是按數(shù)組順序執(zhí)行如果你的人身依賴先處理過的結(jié)構(gòu)就得排在對應(yīng)插件后面。比如你要處理v-if轉(zhuǎn)換后的節(jié)點(diǎn)如果自己的transform排在v-if處理之前那個(gè)節(jié)點(diǎn)上還沒有if結(jié)構(gòu)邏輯可能失效。這塊建議在實(shí)際接入前先寫一個(gè)最小模板驗(yàn)證執(zhí)行順序別等到項(xiàng)目大了再排查。6. 常見問題與排查技巧實(shí)錄6.1 AST節(jié)點(diǎn)被吞或生成的代碼不正確現(xiàn)象Babel插件跑完變量丟了、函數(shù)體變成空殼、代碼結(jié)構(gòu)亂掉。原因八成是visitor里沒有返回新節(jié)點(diǎn)或者用path.remove()刪除了當(dāng)前節(jié)點(diǎn)后還在訪問子節(jié)點(diǎn)。還有一種情況是AST節(jié)點(diǎn)被多處共享一個(gè)visitor改了它另一個(gè)visitor拿著舊引用繼續(xù)操作導(dǎo)致生成代碼錯(cuò)亂。排查先在插件里打日志把path.node的結(jié)構(gòu)打印出來原始AST長什么樣一清二楚。再用babel.transformSync(code, { ast: true, code: false })只拿AST對比處理前后結(jié)構(gòu)。我的習(xí)慣是寫一個(gè)debugPlugin把每個(gè)階段的AST輸出到臨時(shí)文件肉眼對比最快。6.2 渲染函數(shù)執(zhí)行報(bào)錯(cuò)“Cannot read property of undefined”現(xiàn)象頁面白屏控制臺指向render函數(shù)里的_ctx.xxx。原因多半是模板里用了某個(gè)變量但setup沒有返回它或者AST transform階段把表達(dá)式轉(zhuǎn)換成了不存在的字段引用。另外如果codegen拼接函數(shù)名拼錯(cuò)也會有這種詭異報(bào)錯(cuò)。排查先把編譯產(chǎn)物復(fù)制出來在控制臺手動執(zhí)行一遍看具體是哪個(gè)字段undefined。檢查setup返回值和_ctx的對應(yīng)關(guān)系。如果用了自定義transform把編譯前后模板分別跑一遍看看字段引用是否在轉(zhuǎn)換中丟失。我見過不少類似問題是模板里用了v-ifisShow但setup返回的字段叫isVisible這種拼寫錯(cuò)誤在AST階段不會報(bào)錯(cuò)只有運(yùn)行到render函數(shù)時(shí)才會露餡。6.3 視圖替換沒生效現(xiàn)象插件里改了render頁面紋絲不動動態(tài)組件切換后視圖還是舊的自定義指令替換組件沒效果。原因組件被緩存同名組件注冊沖突patch時(shí)key相同導(dǎo)致復(fù)用了舊DOM插件replace的時(shí)機(jī)晚于組件初始化。處理打開vue-devtools看組件樹確認(rèn)實(shí)際渲染的是哪個(gè)組件檢查組件name是否全局唯一如果涉及列表替換臨時(shí)給組件加不同key強(qiáng)制重建。另一個(gè)隱蔽問題是很多人用app.component(HomePage, NewHome)想覆蓋舊組件但頁面里已經(jīng)通過import導(dǎo)入了舊組件這時(shí)候覆蓋的是注冊表里的名字不是實(shí)際用的那個(gè)引用。視圖替換的“最后一公里”往往是緩存和生命周期而不是AST轉(zhuǎn)換。6.4 常見問題排查速查表問題表現(xiàn)可能原因檢查方向插件跑完代碼變成空殼visitor刪除節(jié)點(diǎn)后繼續(xù)訪問子節(jié)點(diǎn)在刪除后return或用path.stop()編譯產(chǎn)物報(bào)未知輔助函數(shù)codegen階段輔助函數(shù)名未匹配檢查編譯目標(biāo)和運(yùn)行時(shí)版本組件switch不生效用了字符串類型is組件未注冊改用組件對象或確認(rèn)全局注冊視圖替換后舊狀態(tài)殘留替換render前未解綁舊組件mixin里保存舊render替換前清理狀態(tài)AST transform順序?qū)е碌漠惓Ｗ远xtransform依賴前序轉(zhuǎn)換用最小模板驗(yàn)證執(zhí)行順序最后分享一點(diǎn)實(shí)操心得跟編譯器、插件打了這么多年交道我最深的體會是AST是最好騙的中間人它完全不理解業(yè)務(wù)但只要你給它正確結(jié)構(gòu)它就能幫你重組整個(gè)世界。很多看著高大上的插件、工具剝開外殼就是“遍歷樹、改節(jié)點(diǎn)、生成代碼”三板斧。最后送大家一個(gè)小技巧設(shè)計(jì)編譯期插件時(shí)一定要分開調(diào)試parse、transform、codegen三段別三步一起跑。先確認(rèn)模板解析出的AST符合預(yù)期再單獨(dú)跑transform比對節(jié)點(diǎn)變化最后再生成代碼執(zhí)行。我之前圖省事直接一把梭結(jié)果出問題后定位成本比寫插件本身還高。先小步驗(yàn)證再全量接入這個(gè)原則不管是寫B(tài)abel插件、Vue插件還是做視圖替換都同樣適用。