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