我們團(tuán)隊(duì)半年前接手了一個(gè)中后臺(tái)項(xiàng)目第一版急著上線組件基本是頁(yè)面拆分法——一個(gè)路由對(duì)應(yīng)一個(gè).vue文件公共部分全靠復(fù)制粘貼。結(jié)果二期需求一來(lái)改動(dòng)點(diǎn)散落在十幾個(gè)文件里一個(gè)按鈕的交互調(diào)整要翻三個(gè)組件改完A處炸了B處。痛定思痛之后我把整個(gè)項(xiàng)目的組件梳理重構(gòu)了一遍這中間踩了不少坑也想明白了很多事。這篇文章不打算講Vue的基礎(chǔ)語(yǔ)法而是聚焦組件化開發(fā)這件事本身邊界怎么劃、數(shù)據(jù)怎么傳、復(fù)用怎么做、性能怎么顧以及我實(shí)際項(xiàng)目里遇到的一些典型問題的完整排查過程。1. 組件粒度的劃分邏輯別把拆文件當(dāng)成組件化很多初學(xué)者理解的組件化就是把一個(gè)頁(yè)面拆成好幾個(gè).vue文件這個(gè)理解不算錯(cuò)但遠(yuǎn)遠(yuǎn)不夠。我在代碼評(píng)審里見過一個(gè)非常典型的問題有人把一個(gè)表單頁(yè)拆成了FormHeader.vue、FormBody.vue、FormFooter.vue看起來(lái)結(jié)構(gòu)清晰但實(shí)際上三個(gè)組件之間用$emit和props傳了幾十個(gè)字段父組件里塞滿了各種回調(diào)函數(shù)改一個(gè)字段校驗(yàn)規(guī)則要在三個(gè)文件里來(lái)回跳。這不是組件化這是把一個(gè)大文件拆成了三個(gè)互相依賴的小文件復(fù)雜度一點(diǎn)沒降反而因?yàn)橥ㄐ懦杀旧吡恕?.1 拆分的本質(zhì)是封裝變化不是切分頁(yè)面組件拆分的真正目的是把會(huì)一起變化的邏輯和視圖收攏在一起把不會(huì)一起變化的邏輯隔離開來(lái)。我傾向于用三個(gè)問題來(lái)判斷一個(gè)組件是否需要拆分這段代碼是否會(huì)在多個(gè)地方復(fù)用這段代碼是否只跟某一塊獨(dú)立的業(yè)務(wù)強(qiáng)相關(guān)跟外層頁(yè)面其他部分沒有直接耦合這段代碼是否有獨(dú)立的狀態(tài)管理需求如果三個(gè)問題的答案都是否那它就只是一段普通的模板片段強(qiáng)行拆成組件反而增加通信成本。比如頁(yè)面頂部的標(biāo)題欄如果整站只有一個(gè)頁(yè)面用到而且只是展示文字那就沒必要抽組件。反之如果項(xiàng)目里有十個(gè)頁(yè)面都要用同一個(gè)用戶選擇器要處理遠(yuǎn)程搜索、多選、回顯、禁用狀態(tài)這種就必須拆——因?yàn)樗型暾?dú)立的交互邏輯和內(nèi)部狀態(tài)。1.2 我目前比較穩(wěn)定的拆分習(xí)慣實(shí)際項(xiàng)目中我總結(jié)了一套自己的拆分節(jié)奏按照業(yè)務(wù)組件 通用組件 基礎(chǔ)組件三層來(lái)做層級(jí)例子特點(diǎn)基礎(chǔ)組件UI組件按鈕、輸入框、彈窗、日期選擇器不感知業(yè)務(wù)純展示基礎(chǔ)交互通常用第三方庫(kù)如Ant Design Vue通用業(yè)務(wù)組件用戶選擇器、部門樹、文件上傳、商品選擇彈窗綁定特定業(yè)務(wù)實(shí)體內(nèi)部有數(shù)據(jù)請(qǐng)求邏輯但跟具體頁(yè)面無(wú)關(guān)頁(yè)面級(jí)業(yè)務(wù)組件訂單表單、商品詳情卡片、審批列表跟頁(yè)面強(qiáng)相關(guān)可以獨(dú)立維護(hù)其他頁(yè)面基本不會(huì)用這個(gè)分層的核心意義在于依賴方向基礎(chǔ)組件不依賴業(yè)務(wù)組件通用業(yè)務(wù)組件不依賴頁(yè)面級(jí)組件。一旦出現(xiàn)反向依賴比如通用組件里引了某個(gè)頁(yè)面的接口復(fù)用性就廢掉了。經(jīng)驗(yàn)心得組件拆分的粒度沒有絕對(duì)標(biāo)準(zhǔn)但有一個(gè)可以落地的檢驗(yàn)方法——如果一個(gè)組件里同時(shí)存在v-for、v-if、多個(gè)props分支判斷、超過三個(gè)$emit事件基本就可以考慮繼續(xù)拆了。反之如果一個(gè)組件只有props展示沒有內(nèi)部狀態(tài)也沒必要為了看起來(lái)組件化而硬拆。2. 組件通信方式的選擇不同場(chǎng)景要用的正確姿勢(shì)Vue組件通信的方式非常多props、$emit、v-model、$refs、provide/inject、事件總線、Pinia、Vuex。很多人能背出API但到了真正的項(xiàng)目里不知道選哪個(gè)。我的經(jīng)驗(yàn)是通信方式的選擇本質(zhì)上是在問一個(gè)問題數(shù)據(jù)之間的依賴關(guān)系是單向的還是雙向的是父子的還是跨層級(jí)的2.1 props/$emit是默認(rèn)選擇但要注意數(shù)據(jù)流向父子通信最普通但也不是隨便用的。我見過有人在props里傳對(duì)象子組件里直接this.propsObj.xxx newVal改屬性這在Vue 2里是能運(yùn)行的但會(huì)破壞單向數(shù)據(jù)流。后續(xù)排查問題的時(shí)候你根本不知道這個(gè)對(duì)象的某個(gè)屬性是被哪個(gè)組件改掉的。正確做法是子組件把修改意圖$emit上去由父組件來(lái)改數(shù)據(jù)!-- 子組件 -- template el-input :model-valuemodelValue update:model-valueval $emit(update:modelValue, val) / /template script setup defineProps([modelValue]) defineEmits([update:modelValue]) /script用v-model語(yǔ)法糖來(lái)簡(jiǎn)化這種受控組件的寫法模板看起來(lái)簡(jiǎn)潔很多而且父組件和子組件的數(shù)據(jù)流仍然保持?jǐn)?shù)據(jù)在父、行為在子的單向邏輯。2.2 provide/inject跨層級(jí)傳遞的邊界provide配inject解決的是跨層級(jí)透?jìng)鲉栴}。比如一個(gè)復(fù)雜頁(yè)面里的根組件向下傳項(xiàng)目上下文信息中間隔了三層組件每層都用props中轉(zhuǎn)太痛苦provide/inject就非常合適。但這里有個(gè)非常常見的坑provide里的數(shù)據(jù)如果不是響應(yīng)式的子組件接收后不會(huì)自動(dòng)更新。我踩過一次在父組件里provide了一個(gè)普通對(duì)象接口返回后改了對(duì)象里的某個(gè)數(shù)組子組件里的inject拿到的還是舊值。排查了半天才發(fā)現(xiàn)問題出在響應(yīng)性上。所以使用provide時(shí)要注意要么直接provide一個(gè)ref、reactive對(duì)象要么用computed包裝一層。// 父組件 const projectInfo ref({ name: , owner: }) provide(projectInfo, projectInfo) // 子組件 const projectInfo inject(projectInfo)這么處理之后接口數(shù)據(jù)更新時(shí)子組件里用到的projectInfo也能自動(dòng)刷新。我一般用provide/inject來(lái)傳遞上下文狀態(tài)——比如當(dāng)前登錄用戶、當(dāng)前項(xiàng)目ID、權(quán)限配置這類全局性的、讀取頻率高且基本不怎么變的數(shù)據(jù)。2.3 事件總線為什么不推薦以及什么時(shí)候真的該用事件總線new Vue()或mitt在Vue 2時(shí)代很流行到了Vue 3雖然也可以實(shí)現(xiàn)但官方已經(jīng)不太推薦了。原因很簡(jiǎn)單全局事件不好追蹤。出問題的時(shí)候你不知道事件是誰(shuí)發(fā)的也不知道誰(shuí)在監(jiān)聽代碼量一大就變成事件滿天飛。而且組件銷毀時(shí)如果忘記off解除監(jiān)聽還會(huì)造成內(nèi)存泄漏。我之前在一個(gè)老項(xiàng)目里查過一個(gè)詭異的bugA頁(yè)面提交表單成功觸發(fā)了B頁(yè)面的數(shù)據(jù)刷新當(dāng)時(shí)就是靠一個(gè)全局事件總線跨頁(yè)面通信最后發(fā)現(xiàn)B頁(yè)面已經(jīng)銷毀了但監(jiān)聽還在反復(fù)提交后頁(yè)面越來(lái)越卡。定位到原因后我把這個(gè)全局事件改成了Pinia里的狀態(tài)管理。但這不代表事件總線完全不能碰。在極少數(shù)場(chǎng)景下比如多個(gè)組件需要共同響應(yīng)一個(gè)外部系統(tǒng)事件比如WebSocket推送消息、全局快捷鍵用一個(gè)統(tǒng)一的mitt實(shí)例還是比在每個(gè)組件里各自管理生命周期要省事。這種情況下把事件名定義成常量集中管理并且組件卸載時(shí)記得off問題也不大。2.4 Pinia是跨組件共享數(shù)據(jù)的最終歸屬當(dāng)數(shù)據(jù)需要在多個(gè)非父子組件之間共享或者多個(gè)組件要修改同一個(gè)數(shù)據(jù)源時(shí)我強(qiáng)烈建議直接上Pinia。相比VuexPinia的API更簡(jiǎn)潔去掉了mutations那一層直接在store里寫函數(shù)改state配合setup風(fēng)格的store寫法心智負(fù)擔(dān)低很多。在實(shí)際組件化項(xiàng)目里Pinia通常用來(lái)承載真正的全局狀態(tài)用戶信息、權(quán)限點(diǎn)、購(gòu)物車、或者某個(gè)跨頁(yè)面需要保持一致的數(shù)據(jù)。需要注意的是盡量不要把所有的數(shù)據(jù)都塞進(jìn)store。有時(shí)候父子組件之間傳遞最簡(jiǎn)單的開關(guān)狀態(tài)也用store反而會(huì)讓組件失去獨(dú)立性。我推薦的判斷標(biāo)準(zhǔn)是如果這個(gè)組件的復(fù)用性要求很高它的內(nèi)部數(shù)據(jù)就不要依賴store而應(yīng)該通過props傳入。這樣以后放到任何頁(yè)面都能直接用不用先建一堆store才能跑。3. 插槽設(shè)計(jì)讓組件真正具備擴(kuò)展能力如果你只把組件做成封裝起來(lái)的一整塊頁(yè)面那它注定很難復(fù)用因?yàn)楝F(xiàn)實(shí)中的業(yè)務(wù)總有那么一點(diǎn)點(diǎn)不同同樣的彈窗組件A頁(yè)面要加一個(gè)輸入框B頁(yè)面要加一個(gè)表格C頁(yè)面要改按鈕文案。這時(shí)候如果每個(gè)差異都用props去控制組件會(huì)膨脹成一個(gè)巨大的if/else怪物。Vue里更好的解法是插槽slot。3.1 作用域插槽的正確用法插槽不只是往組件里塞一段模板這么簡(jiǎn)單作用域插槽允許子組件向插槽內(nèi)容傳遞數(shù)據(jù)這樣父組件就能在插槽里拿到子組件的狀態(tài)來(lái)定制展示。舉個(gè)例子我封裝過一個(gè)通用的AsyncSelect組件它負(fù)責(zé)遠(yuǎn)程搜索、防抖、loading狀態(tài)、下拉選項(xiàng)數(shù)據(jù)管理。但不同頁(yè)面對(duì)選項(xiàng)渲染的需求不同有的地方要顯示頭像昵稱有的地方只要顯示部門名。如果我把選項(xiàng)渲染寫死在組件里就沒法復(fù)用了。于是我用作用域插槽把選項(xiàng)數(shù)據(jù)暴露出去AsyncSelect :fetch-apifetchUsers template #option{ item } div classuser-option el-avatar :srcitem.avatar sizesmall / span{{ item.name }}{{ item.dept }}/span /div /template /AsyncSelect這樣AsyncSelect只負(fù)責(zé)數(shù)據(jù)獲取和交互邏輯具體的展示樣式由使用方?jīng)Q定。組件本身不關(guān)心你在選項(xiàng)里顯示什么。3.2 具名插槽與預(yù)留擴(kuò)展位的思路組件封裝的另一個(gè)經(jīng)驗(yàn)是從一開始就預(yù)留擴(kuò)展位。哪怕當(dāng)前只有一個(gè)插槽需求也建議把組件內(nèi)部的關(guān)鍵位置用具名插槽暴露出來(lái)。比如一個(gè)Card組件默認(rèn)有header和footer但內(nèi)容區(qū)域到底放什么完全由外部決定。這樣后續(xù)出現(xiàn)新的業(yè)務(wù)需求時(shí)你不需要去改被復(fù)用的老組件而是通過插槽內(nèi)容做擴(kuò)展安全得多。我在重構(gòu)項(xiàng)目時(shí)把原來(lái)一個(gè)寫死的OrderDetail組件改成了多個(gè)區(qū)域插槽頂部信息、商品明細(xì)、操作按鈕、擴(kuò)展信息區(qū)。結(jié)果后來(lái)新增了一個(gè)物流跟蹤需求完全不需要?jiǎng)雍诵慕M件只在外部調(diào)用時(shí)往擴(kuò)展信息區(qū)塞了一個(gè)LogisticsTimeline組件就搞定了。這就是插槽帶來(lái)的解耦能力。4. 組件狀態(tài)管理與生命周期最容易踩坑的地方很多人對(duì)組件化開發(fā)的理解停留在模板怎么寫、組件怎么拆但真正到項(xiàng)目中跑起來(lái)生命周期和狀態(tài)同步才是最容易出問題的環(huán)節(jié)。我整理了幾個(gè)實(shí)戰(zhàn)中反復(fù)遇到的坑以及最終的排查方案。4.1 組件復(fù)用導(dǎo)致的數(shù)據(jù)殘留有一段場(chǎng)景一個(gè)列表頁(yè)點(diǎn)擊編輯按鈕打開一個(gè)彈窗組件彈窗里是一個(gè)表單。第一版代碼彈窗是用v-if控制的打開時(shí)創(chuàng)建組件關(guān)閉時(shí)銷毀組件。后來(lái)為了優(yōu)化體驗(yàn)改成用v-show控制顯隱結(jié)果出現(xiàn)了一個(gè)很隱蔽的bugA記錄編輯到一半關(guān)閉彈窗再打開編輯B記錄表單里還是A記錄的數(shù)據(jù)。排查過程先懷疑是表單初始化邏輯沒觸發(fā)檢查created和mounted——發(fā)現(xiàn)組件在v-show下根本不會(huì)重新走生命周期鉤子只有v-if才會(huì)重新創(chuàng)建組件。解決方案有三種方案一保留v-if但增加一個(gè)key來(lái)強(qiáng)制組件重建比如:keycurrentRecord.id。這樣每次打開不同記錄時(shí)Vue會(huì)認(rèn)為這是一個(gè)新組件走完整的初始化流程。方案二用watch監(jiān)聽外部傳入的visible或currentRecord在彈窗打開時(shí)手動(dòng)重置表單數(shù)據(jù)。方案三通過$refs調(diào)用子組件暴露的resetForm方法。我落地時(shí)選擇了方案一因?yàn)樗那秩胱钚《襨ey變化后組件內(nèi)部所有狀態(tài)都是全新的不會(huì)殘留。4.2 為什么明明數(shù)據(jù)變了界面不更新另一類高頻問題是修改了數(shù)據(jù)但視圖不動(dòng)。在Vue 3的reactive和ref設(shè)計(jì)中一般不會(huì)出現(xiàn)屬性新增不響應(yīng)這類Vue 2時(shí)代的坑但有一種情況很容易被忽略在computed里直接修改state。比如有人寫了這樣的代碼const count computed({ get() { return store.count }, set(val) { store.count val // 直接改store } })這本身問題不大但如果count被多個(gè)組件引用而且set邏輯里還帶副作用就會(huì)造成一個(gè)組件改了值其他組件也間接受影響但依賴鏈復(fù)雜到根本看不出是誰(shuí)改的。排查這一類問題我建議用Vue Devtools的組件樹和Pinia面板直接看當(dāng)前組件的computed依賴關(guān)系能比較快地定位到被修改的數(shù)據(jù)源。4.3 組件銷毀時(shí)的清理工作組件化開發(fā)中onUnmountedVue 3階段是很多人會(huì)忽略的。如果組件里創(chuàng)建了setInterval、addEventListener、WebSocket連接或者訂閱了mitt事件必須在銷毀時(shí)清理否則頁(yè)面切換多了就會(huì)卡頓甚至報(bào)錯(cuò)。我寫過這樣一個(gè)組件它內(nèi)部用一個(gè)輪詢?nèi)ニ⑿聰?shù)據(jù)當(dāng)時(shí)的代碼如下onMounted(() { this.timer setInterval(fetchData, 3000) })后來(lái)我在路由里反復(fù)進(jìn)入退出這個(gè)頁(yè)面發(fā)現(xiàn)接口請(qǐng)求次數(shù)越來(lái)越多頁(yè)面也越來(lái)越卡。用DevTools的Performance面板一查發(fā)現(xiàn)每進(jìn)入一次都多了一個(gè)setInterval因?yàn)榕f組件的定時(shí)器沒有清掉。加上onUnmounted里clearInterval之后就正常了。寫組件時(shí)我現(xiàn)在的習(xí)慣是所有在onMounted里打開的資源都必須在onUnmounted里關(guān)閉。這個(gè)習(xí)慣比等出問題再去查高效得多。5. 組件的復(fù)用與擴(kuò)展把單一職責(zé)貫徹到業(yè)務(wù)組件業(yè)務(wù)組件的復(fù)用比基礎(chǔ)組件要難得多。因?yàn)榛A(chǔ)組件通常只是展示交互業(yè)務(wù)組件卻包含了數(shù)據(jù)請(qǐng)求、權(quán)限判斷、業(yè)務(wù)狀態(tài)等復(fù)雜邏輯。如果邊界沒劃好很容易變成看起來(lái)復(fù)用實(shí)際上改都改不動(dòng)。5.1 通用業(yè)務(wù)組件的封裝要點(diǎn)以前面說的AsyncSelect為例一個(gè)可復(fù)用的業(yè)務(wù)組件應(yīng)該具備這幾個(gè)特征數(shù)據(jù)獲取能力由外部傳入通過props傳fetchApi組件內(nèi)部不寫死任何接口內(nèi)部狀態(tài)完整搜索詞、loading、選項(xiàng)列表、選中值、下拉開關(guān)全部由組件自己管理對(duì)外暴露最小必要接口modelValue雙向綁定、placeholder、disabled等常規(guī)屬性關(guān)鍵展示位用插槽暴露方便外部定制如果業(yè)務(wù)組件里寫死了某個(gè)后端的請(qǐng)求地址或者內(nèi)部調(diào)用了其他業(yè)務(wù)模塊的狀態(tài)那這個(gè)組件的復(fù)用面就非常窄了。封裝時(shí)的核心思想是把變的部分留給使用者把不變的部分沉淀在組件內(nèi)部。5.2 組合式函數(shù)Composables復(fù)用的是邏輯不是組件還有一些場(chǎng)景組件本身不適合復(fù)用但邏輯值得復(fù)用。比如列表頁(yè)的搜索、分頁(yè)、重置這套流程在很多頁(yè)面里都一樣但頁(yè)面的模板結(jié)構(gòu)完全不同。這時(shí)候硬抽公共組件反而不靈活更好的做法是用組合式函數(shù)useSearchList把邏輯抽出來(lái)。export function useSearchList(fetchApi, { defaultParams {} } {}) { const loading ref(false) const list ref([]) const total ref(0) const params reactive({ ...defaultParams }) async function getList() { loading.value true try { const res await fetchApi(params) list.value res.list total.value res.total } finally { loading.value false } } function reset() { Object.keys(params).forEach(k delete params[k]) Object.assign(params, defaultParams) getList() } return { loading, list, total, params, getList, reset } }這樣每個(gè)頁(yè)面只需要少量模板代碼就能復(fù)用整套搜索列表邏輯。相比組件復(fù)用這種方式更輕量也更靈活。組件負(fù)責(zé)復(fù)用視覺交互Composable負(fù)責(zé)復(fù)用純邏輯兩種手段配合使用覆蓋的場(chǎng)景才完整。5.3 先寫代碼再抽象不要過度設(shè)計(jì)我自己之前犯過一個(gè)錯(cuò)誤就是做組件的時(shí)候想著以后可能會(huì)擴(kuò)展加入了很多當(dāng)時(shí)根本用不到的配置項(xiàng)和邏輯分支。結(jié)果代碼復(fù)雜了測(cè)試覆蓋也沒跟上后來(lái)真正有擴(kuò)展需求的時(shí)候才發(fā)現(xiàn)當(dāng)初預(yù)設(shè)的分支跟實(shí)際需求完全對(duì)不上改動(dòng)反而更大?，F(xiàn)在我的做法是先讓組件在至少兩個(gè)真實(shí)業(yè)務(wù)場(chǎng)景里跑通然后再根據(jù)這兩個(gè)場(chǎng)景的共性和差異做抽象。如果只有一個(gè)場(chǎng)景在用抽出來(lái)的通用性很可能是假的。真正可復(fù)用的組件是在反復(fù)迭代中沉淀出來(lái)的而不是靠一次性設(shè)計(jì)出來(lái)的。6. 組件渲染性能優(yōu)化從能用到流暢組件化開發(fā)做到后期性能是一個(gè)繞不開的話題。尤其當(dāng)頁(yè)面里有很多嵌套組件、長(zhǎng)列表、復(fù)雜表格的時(shí)候渲染性能直接決定了體驗(yàn)。6.1 用computed緩存派生狀態(tài)避免重復(fù)計(jì)算很多人寫模板里的過濾和計(jì)算時(shí)習(xí)慣直接在模板里寫方法template div{{ formatTime(item.createTime) }}/div /template script setup function formatTime(time) { /* ... */ } /script這個(gè)寫法的問題是只要組件重新渲染formatTime就會(huì)被重新執(zhí)行。如果列表有幾百條每條都調(diào)用一次性能就是幾百次函數(shù)調(diào)用。更合理的做法是把計(jì)算結(jié)果變成computed或者直接在數(shù)據(jù)層面格式化好。尤其當(dāng)計(jì)算邏輯依賴多個(gè)響應(yīng)式屬性時(shí)computed是有緩存機(jī)制的只有依賴變化時(shí)才重新計(jì)算性能提升非常明顯。6.2 v-if與v-show的選擇還有一個(gè)老生常談但經(jīng)常被用錯(cuò)的問題v-if和v-show。我見過有人把一個(gè)大段組件用v-show控制導(dǎo)致初始化時(shí)就渲染了所有子組件即使它根本不可見也有人把切換頻繁的按鈕用v-if導(dǎo)致每次點(diǎn)擊都要重新創(chuàng)建銷毀組件。我的選擇標(biāo)準(zhǔn)很簡(jiǎn)單如果元素只在初始時(shí)渲染一次后續(xù)基本不變用v-if如果元素切換頻繁且內(nèi)部邏輯不復(fù)雜用v-show如果元素內(nèi)部包含大量子組件和復(fù)雜狀態(tài)盡量避免v-show因?yàn)樗m然隱藏了元素但并沒有銷毀組件組件內(nèi)部的onMounted、定時(shí)器、數(shù)據(jù)請(qǐng)求都還在跑6.3 長(zhǎng)列表的性能優(yōu)化中后臺(tái)項(xiàng)目里長(zhǎng)表格、長(zhǎng)列表非常常見。幾千條數(shù)據(jù)一次性渲染頁(yè)面會(huì)明顯卡頓。我的優(yōu)化思路分幾步讓后端做分頁(yè)前端只展示當(dāng)前頁(yè)數(shù)據(jù)這是最簡(jiǎn)單有效的方式。如果必須一次性加載大量數(shù)據(jù)考慮用虛擬滾動(dòng)——只渲染可視區(qū)域內(nèi)的DOM滾動(dòng)時(shí)動(dòng)態(tài)替換。盡量避免在列表項(xiàng)組件里放太復(fù)雜的子組件列表項(xiàng)越輕滾動(dòng)越流暢。虛擬滾動(dòng)實(shí)現(xiàn)起來(lái)有一定成本但網(wǎng)上有不少成熟的方案如vue-virtual-scroller,如果項(xiàng)目確實(shí)需要可以直接引庫(kù)。不過拿這個(gè)庫(kù)之前一定要自己拉一下demo試一下因?yàn)橛行┨摂M滾動(dòng)方案跟表格的固定列、多級(jí)表頭組合時(shí)會(huì)有兼容問題。6.4 借助Vue Devtools定位性能瓶頸排查組件性能問題時(shí)我一般會(huì)打開Vue Devtools的性能標(biāo)簽頁(yè)錄制一段交互操作然后看每個(gè)組件的渲染耗時(shí)、依賴追蹤情況。排查的優(yōu)先級(jí)是先看是否有組件在數(shù)據(jù)不變時(shí)仍然頻繁重渲染如果有檢查它的props和computed是否穩(wěn)定再看是否有大組件內(nèi)部存在嵌套過深的子組件樹考慮用v-memo、shallowRef或拆分異步組件最后看網(wǎng)絡(luò)請(qǐng)求是否有組件mounted時(shí)同時(shí)發(fā)起了多個(gè)重復(fù)請(qǐng)求Vue 3.2提供的v-memo指令在某些場(chǎng)景下非常有用。比如一個(gè)列表里每一項(xiàng)組件都依賴一個(gè)選中狀態(tài)而選中狀態(tài)只在一個(gè)時(shí)刻改變一個(gè)值但模板里其他內(nèi)容沒有變化時(shí)用v-memo可以直接跳過不必要的diff。不過v-memo要求你非常清楚依賴是什么用錯(cuò)了反而會(huì)導(dǎo)致界面不更新所以我建議項(xiàng)目中有限度使用。7. 幾個(gè)真實(shí)業(yè)務(wù)場(chǎng)景的完整復(fù)盤光講理論容易飄。這里挑三個(gè)我在真實(shí)項(xiàng)目里對(duì)接過的組件化難點(diǎn)完整走一遍從問題出現(xiàn)到最終落地的過程。7.1 百度地圖組件第一次打開正常第二次一片空白這是熱搜詞里出現(xiàn)的一個(gè)典型問題。我在一個(gè)項(xiàng)目中封裝了地圖選擇器組件第一次進(jìn)入頁(yè)面地圖正常顯示切換路由再回來(lái)地圖區(qū)域變成空白。排查過程中我先確認(rèn)了組件確實(shí)走過了onMounted地圖實(shí)例也創(chuàng)建了但容器DOM的寬高在初始化時(shí)是0。這個(gè)問題的根因是百度地圖初始化的時(shí)機(jī)和DOM的渲染時(shí)機(jī)不同步。當(dāng)組件被路由切換重建時(shí)地圖容器雖然掛載了但布局尚未穩(wěn)定寬高還沒被計(jì)算出來(lái)地圖初始化就會(huì)失敗。我在排查時(shí)先驗(yàn)證了延遲初始化的思路在nextTick后再setTimeout(0)初始化地圖但這個(gè)方案并不穩(wěn)定。最終我采用了兩個(gè)保險(xiǎn)在onMounted里用nextTick確保DOM布局完成后再初始化地圖。給地圖容器設(shè)置一個(gè)固定的min-height避免寬高為0。同時(shí)用一個(gè)key綁定到組件上當(dāng)?shù)貓D容器重新創(chuàng)建時(shí)強(qiáng)制地圖實(shí)例重新初始化。這個(gè)案例給我的經(jīng)驗(yàn)是組件在二次打開時(shí)產(chǎn)生問題多半是生命周期和外部依賴如地圖、富文本編輯器、圖表的初始化時(shí)序沒有對(duì)齊而且排查時(shí)不要一股腦去懷疑框架先確認(rèn)DOM狀態(tài)和外部庫(kù)需要的條件是否滿足。7.2 el-select遠(yuǎn)程搜索下拉滾動(dòng)加載更多另一個(gè)熱搜詞是el-select可以遠(yuǎn)程搜索下拉框可以滾動(dòng)請(qǐng)求更多數(shù)據(jù)。中后臺(tái)里這是非常常見的需求。難點(diǎn)在于遠(yuǎn)程搜索需要防抖避免每輸入一個(gè)字符就請(qǐng)求一次下拉滾動(dòng)到底部時(shí)需要加載下一頁(yè)數(shù)據(jù)并且去重已選中的選項(xiàng)即使不在當(dāng)前搜索結(jié)果里也要回顯我封裝的方案是組件內(nèi)部維護(hù)options數(shù)組、page和keyword狀態(tài)搜索時(shí)重置page1并請(qǐng)求第一頁(yè)數(shù)據(jù)滾動(dòng)到底時(shí)page繼續(xù)請(qǐng)求用Map去重選中后把選中的對(duì)象單獨(dú)存放在一個(gè)selectedOption里讓顯示值可以正?；仫@。代碼結(jié)構(gòu)大概是el-select v-modelselectedValue filterable remote :remote-methoddebouncedSearch visible-changehandleVisibleChange el-option v-foropt in options :keyopt.id :labelopt.name :valueopt.id / /el-select這里有個(gè)容易踩的坑remote-method觸發(fā)的時(shí)機(jī)比你想象中頻繁如果沒做防抖接口會(huì)被打爆。我習(xí)慣用lodash.debounce包一層或者自己寫個(gè)簡(jiǎn)單的定時(shí)器版本。另一個(gè)坑是滾動(dòng)加載的容器不是頁(yè)面而是el-select的下拉彈層要監(jiān)聽的是那個(gè)彈層容器的scroll事件而不是頁(yè)面的scroll。這個(gè)彈層在DOM里可能不在組件內(nèi)部所以不能用scroll直接綁定需要在onMounted后拿到彈層的DOM元素添加監(jiān)聽并在onUnmounted時(shí)移除。7.3 飛書免登錄跳轉(zhuǎn)Vue項(xiàng)目時(shí)的登錄態(tài)不同步這個(gè)場(chǎng)景更偏向于多系統(tǒng)集成中的組件邊界設(shè)計(jì)。實(shí)際項(xiàng)目中遇到的需求大致是從飛書的工作臺(tái)點(diǎn)擊應(yīng)用圖標(biāo)跳轉(zhuǎn)到我們的Vue項(xiàng)目需要自動(dòng)完成登錄而不是讓用戶再輸一次賬號(hào)密碼。這里的關(guān)鍵不是組件本身而是應(yīng)用啟動(dòng)時(shí)的會(huì)話打通。我們的做法是在路由前置守衛(wèi)里放一個(gè)全局的登錄攔截如果本地沒有token就嘗試用飛書跳轉(zhuǎn)參數(shù)里的臨時(shí)憑證去換取服務(wù)端的登錄態(tài)。換取成功后再繼續(xù)路由跳轉(zhuǎn)失敗則跳轉(zhuǎn)到登錄頁(yè)。從組件化的角度看這個(gè)登錄攔截本質(zhì)上是**整個(gè)應(yīng)用的最高層組件或路由守衛(wèi)**在統(tǒng)一處理而不是每個(gè)頁(yè)面組件各自判斷。如果每個(gè)頁(yè)面都去處理是否已登錄的邏輯代碼會(huì)非常分散也很難維護(hù)。正確的做法是把這類與應(yīng)用生命周期強(qiáng)相關(guān)的邏輯收斂到全局而不是散落在各個(gè)業(yè)務(wù)組件里。8. 復(fù)盤哪些組件化最佳實(shí)踐其實(shí)是偽需求寫了這么多我想最后聊一個(gè)反直覺的話題。網(wǎng)上很多文章都在強(qiáng)調(diào)組件要足夠通用、足夠解耦、配置要靈活但我的實(shí)際體會(huì)是過度追求這些往往比不拆分更糟糕。我接手過一套組件庫(kù)里面每個(gè)組件都有十幾個(gè)props、四五個(gè)插槽、還有一堆computed動(dòng)態(tài)判斷?？雌饋?lái)非常強(qiáng)大但真正用的時(shí)候大部分props從沒被傳入過大部分插槽也從沒被使用過。反而因?yàn)榇a分支太多任何一個(gè)小改動(dòng)都要回歸測(cè)試一大堆場(chǎng)景。一個(gè)組件真正被復(fù)用的前提是在真實(shí)場(chǎng)景中確實(shí)出現(xiàn)了復(fù)用的需求。與其在一開始就設(shè)計(jì)一個(gè)萬(wàn)能組件不如在第一個(gè)使用場(chǎng)景里把組件做到剛好夠用在第二個(gè)使用場(chǎng)景出現(xiàn)時(shí)再根據(jù)差異抽象出擴(kuò)展點(diǎn)。我在重構(gòu)項(xiàng)目時(shí)發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象真正被復(fù)用的組件往往是在三個(gè)以上的頁(yè)面中都長(zhǎng)得很像的那部分而那些當(dāng)初精心設(shè)計(jì)的萬(wàn)能組件反而因?yàn)闆]人敢用最終成了死代碼。組件化的價(jià)值是讓系統(tǒng)的復(fù)雜度可控不是讓組件數(shù)量變多。每抽出一個(gè)組件都應(yīng)該讓代碼邏輯更清晰、改動(dòng)面更小、可讀性更高。如果拆完之后發(fā)現(xiàn)改動(dòng)一個(gè)功能要同時(shí)改三個(gè)組件那大概率是拆分方向出了問題而不是組件化本身沒用。另一個(gè)體會(huì)跟組件命名有關(guān)。好的組件名應(yīng)該讓人一看就知道它是干嘛的而且要能看明白它的層級(jí)。項(xiàng)目里我見過大量index.vue文件點(diǎn)進(jìn)去才知道是什么組件。雖然這是很多腳手架默認(rèn)生成的命名但長(zhǎng)期維護(hù)下來(lái)這種命名方式真的會(huì)增加定位成本。我現(xiàn)在的做法是通用組件名用名詞名詞如UserSelect、DeptTree頁(yè)面組件名用頁(yè)面名業(yè)務(wù)名如OrderDetailPanel盡量不用index.vue作為唯一命名。組件化開發(fā)這條路沒有標(biāo)準(zhǔn)答案但有一些共性的原則邊界要清晰、數(shù)據(jù)流要可追蹤、復(fù)用要基于真實(shí)需求、性能要有意識(shí)地去關(guān)注。每次你拿到一個(gè)需求先不要急著寫模板花幾分鐘想想這個(gè)功能跟其他頁(yè)面的現(xiàn)有能力是什么關(guān)系哪些東西應(yīng)該收斂到組件內(nèi)部哪些能力應(yīng)該以插槽或props的形式對(duì)外暴露想清楚了再動(dòng)手后面的維護(hù)成本會(huì)低很多。