前端開發(fā)的日常里最繞不開的一類需求就是組件間通信。列表頁(yè)點(diǎn)了加購(gòu)購(gòu)物車的角標(biāo)要跟著跳數(shù)字菜單組件選中變了路由要切換到新頁(yè)面彈窗組件關(guān)掉的瞬間頁(yè)面列表最好能自動(dòng)刷新。這些事情單靠組件各自悶頭干活是完成不了的必須有清晰的數(shù)據(jù)傳遞通道。我見過(guò)很多項(xiàng)目功能都能跑但一改需求就四處冒煙原因往往就出在通信鏈路上沒(méi)有好好設(shè)計(jì)。這篇文章不打算堆概念我就從實(shí)戰(zhàn)關(guān)系出發(fā)把父子通信、跨層通信、全局狀態(tài)管理這幾條路線的原理、選型思路和常見坑位都過(guò)一遍。適合正在學(xué)組件化開發(fā)的朋友也適合項(xiàng)目里通信邏輯已經(jīng)寫成一團(tuán)亂麻、想重新梳理方案的人。你可以把它當(dāng)成一張組件間通信的選型地圖需要的時(shí)候翻到對(duì)應(yīng)章節(jié)找答案。1. 組件間通信的前置認(rèn)知先搞清楚誰(shuí)該擁有數(shù)據(jù)1.1 組件的本質(zhì)是一個(gè)函數(shù)通信就是函數(shù)間的調(diào)用關(guān)系組件這個(gè)東西寫到最后你會(huì)發(fā)現(xiàn)它跟函數(shù)非常像。props是入?yún)mit是向外拋出結(jié)果的回調(diào)插槽是在固定的模板位置上留出擴(kuò)展口組合式API則像是把函數(shù)內(nèi)部的邏輯拆得更細(xì)。你寫一個(gè)函數(shù)不會(huì)讓兩個(gè)函數(shù)之間互相改對(duì)方的局部變量你在設(shè)計(jì)組件時(shí)也不該讓一個(gè)組件的狀態(tài)直接被另一個(gè)組件隨便改動(dòng)。組件間通信的規(guī)范本質(zhì)上是在模仿一種干凈的調(diào)用約定。很多新手一上來(lái)就追著某個(gè)具體API學(xué)比如props怎么傳、emit怎么寫這當(dāng)然要學(xué)但更值得先想清楚的是數(shù)據(jù)所有權(quán)。一個(gè)用戶姓名到底應(yīng)該放在父組件還是子組件里還是直接放進(jìn)全局的store判斷標(biāo)準(zhǔn)很簡(jiǎn)單看它會(huì)被誰(shuí)使用。只有子組件自己用就放在子組件父組件要用就提升到父組件頁(yè)面上多個(gè)角落都要用且互不嵌套才輪到全局狀態(tài)出場(chǎng)。數(shù)據(jù)放對(duì)位置之后通信問(wèn)題通常會(huì)少掉一半。React那邊其實(shí)也是這樣props下行、回調(diào)上行跨層級(jí)用Context全局用Redux或Zustand。各家框架的API長(zhǎng)相不同背后那套數(shù)據(jù)歸誰(shuí)所有、怎樣流轉(zhuǎn)的決策模型卻是通用的。理解到這一層后面換什么框架都不費(fèi)勁。1.2 沒(méi)有通信時(shí)項(xiàng)目會(huì)怎樣以購(gòu)物車場(chǎng)景為例為了讓后面的內(nèi)容不飄在空中我拿一個(gè)具體的例子貫穿全文商城頁(yè)面。這個(gè)頁(yè)面由四層組成。最外層是商品列表頁(yè)里面放著一堆商品卡片每張卡片由子組件渲染卡片內(nèi)部又有一個(gè)加購(gòu)按鈕組件。按鈕屬于第三層頁(yè)面底部的購(gòu)物車角標(biāo)可能在另一個(gè)完全不同的位置組件里。如果沒(méi)有通信機(jī)制按鈕組件點(diǎn)擊之后它的內(nèi)部狀態(tài)自己知道了但商品卡片不知道、商品列表不知道、購(gòu)物車角標(biāo)更不知道。你想想用戶點(diǎn)了加購(gòu)界面上一丁點(diǎn)反應(yīng)都沒(méi)有這是沒(méi)法接受的。想要角標(biāo)更新信息必須從最內(nèi)層一路傳遞到最外層再通知角標(biāo)組件重新計(jì)算。這一路上每一步都在做通信按鈕通知卡片卡片通知列表列表把新數(shù)量交給角標(biāo)。哪一步斷了整條鏈路就斷了。這也是為什么通信方案會(huì)成為一種設(shè)計(jì)問(wèn)題而不只是語(yǔ)法問(wèn)題。你選擇的每一條傳遞鏈路都會(huì)影響下一步出問(wèn)題時(shí)排查的路徑影響代碼在哪里會(huì)被修改影響組件復(fù)用的時(shí)候要帶多少周邊依賴。組件間通信從來(lái)不只是把數(shù)據(jù)傳過(guò)去這么簡(jiǎn)單。1.3 先分類再看方案父子、兄弟、跨層的關(guān)系梳理把通信關(guān)系分類分類標(biāo)準(zhǔn)就一條組件在組件樹上的位置關(guān)系。我習(xí)慣分三類來(lái)看。第一類是父子通信直接嵌套最常見的場(chǎng)景。第二類是兄弟通信兩個(gè)組件在同一個(gè)父組件下面但彼此互不嵌套。第三類是跨層通信組件中間隔了好幾層數(shù)據(jù)要穿透層級(jí)才能到達(dá)目標(biāo)。這三類關(guān)系對(duì)應(yīng)的首選方案差別很大。我這里先給結(jié)論父子之間優(yōu)先用props配合emit這是最直觀、最好排查的方式兄弟之間優(yōu)先把數(shù)據(jù)提升到共同的父組件由父組件做中轉(zhuǎn)跨層且傳遞路徑太深才考慮provide/inject或全局狀態(tài)管理全局狀態(tài)管理是最后的兜底不要一上來(lái)就用。把關(guān)系歸類好之后再去挑工具思路會(huì)清楚很多。很多人寫著寫著把代碼寫亂了根源往往不是API不會(huì)用而是沒(méi)先停下來(lái)做這一步分類。2. 父子通信的兩件套props向下emit向上2.1 props不是簡(jiǎn)單的傳參而是單向下行的數(shù)據(jù)契約在Vue 3的組件里父組件通過(guò)props把數(shù)據(jù)交給子組件。子組件用defineProps聲明接收哪些參數(shù)這個(gè)編譯宏不需要額外import。寫起來(lái)大概是這樣的!-- 父組件 -- template product-card :productproduct :show-stocktrue / /template!-- 子組件 ProductCard.vue -- script setup const props defineProps({ product: { type: Object, required: true }, showStock: { type: Boolean, default: false } }); /script這里有個(gè)關(guān)鍵點(diǎn)props的方向是單向的。父組件的數(shù)據(jù)變化會(huì)順著props自動(dòng)流到子組件但子組件永遠(yuǎn)不能反向修改props。我見過(guò)不少新人直接寫props.product.title xxx在Vue 3里這樣改通常不會(huì)立刻報(bào)錯(cuò)但它破壞了數(shù)據(jù)流向會(huì)帶來(lái)一個(gè)非常難排查的隱性問(wèn)題同一個(gè)數(shù)據(jù)在頁(yè)面多處渲染子組件改了一處其他位置的行為變得不可預(yù)期。正確做法是子組件把修改需求通過(guò)emit拋給父組件由父組件來(lái)決定要不要改、怎么改。為什么一定要這么繞因?yàn)樗ＷC了數(shù)據(jù)源只有一個(gè)。父組件是唯一擁有者子組件只是借用者。出現(xiàn)bug時(shí)你永遠(yuǎn)知道去哪里追根溯源。這跟現(xiàn)實(shí)里的審批流很像底層可以提申請(qǐng)但最終決策權(quán)在上一級(jí)。規(guī)則本身不復(fù)雜難的是在寫出順手代碼時(shí)還能忍住不去打破這條約定。2.2 事件向上defineEmits與事件名這件事配合props下行的是emit上行。子組件不直接改父組件的數(shù)據(jù)而是把我想要你做什么發(fā)出去。在Vue 3中定義事件用defineEmits!-- 子組件 ProductCard.vue -- script setup const emit defineEmits([add-to-cart]); function handleClick() { emit(add-to-cart, props.product); } /script父組件在使用子組件時(shí)監(jiān)聽template product-card :productproduct add-to-cartonAddToCart / /template這里最容易踩的坑是事件命名。在模板里監(jiān)聽事件時(shí)瀏覽器最終會(huì)把事件名轉(zhuǎn)成小寫所以如果你在子組件里emit了addToCart模板里寫add-to-cart或addToCart在不同環(huán)境下可能發(fā)生匹配不上。穩(wěn)妥的做法是事件名統(tǒng)一用kebab-case比如add-to-cart模板里也寫成add-to-cart兩邊完全一致不給自己留隱患。另外在script setup里defineEmits只是聲明并不負(fù)責(zé)自動(dòng)觸發(fā)真正觸發(fā)還是要手動(dòng)調(diào)用emit。聲明有什么用一是自文檔化父組件和編輯器插件能識(shí)別這個(gè)子組件對(duì)外拋什么事件二是顯式列出有哪些對(duì)外接口后續(xù)維護(hù)的人不至于靠猜。實(shí)際項(xiàng)目中如果子組件要對(duì)外拋的事件超過(guò)三四個(gè)我會(huì)停下來(lái)想想是不是子組件的職責(zé)太雜了該拆了。2.3 v-model其實(shí)是通信的語(yǔ)法糖有一個(gè)寫法很多人沒(méi)意識(shí)到它本質(zhì)上也是組件間通信就是v-model。在自定義組件上使用v-model等價(jià)于給組件傳了一個(gè)叫modelValue的prop同時(shí)監(jiān)聽了一個(gè)叫update:modelValue的事件。子組件內(nèi)部寫成script setup const props defineProps([modelValue]); const emit defineEmits([update:modelValue]); function updateValue(value) { emit(update:modelValue, value); } /script這樣做的好處是父組件里的語(yǔ)法非常干凈template search-input v-modelkeyword / /template這行代碼把props的下行和emit的上行同時(shí)封裝進(jìn)了一個(gè)指令父組件只關(guān)心keyword變了不用親自處理監(jiān)聽。如果你的子組件是對(duì)外提供輸入、選擇這類值型交互的組件用v-model這種雙向綁定的語(yǔ)法糖會(huì)比手動(dòng)維護(hù)props和emit各來(lái)一套舒服得多。在Vue 3.4之后還可以用defineModel讓這個(gè)模式寫起來(lái)更短但背后的通信原理沒(méi)有變。這里要補(bǔ)充的是不要因?yàn)関-model用起來(lái)方便就把所有兄弟通信都塞給v-model去硬綁定。v-model適用的是父子之間一個(gè)值的同步涉及復(fù)雜對(duì)象的多字段同步時(shí)強(qiáng)行上v-model會(huì)讓模板里的邏輯變得難以閱讀。通信手段的選擇永遠(yuǎn)是簡(jiǎn)潔和可維護(hù)優(yōu)先。3. 跨層與兄弟通信的替代路線provide/inject、事件總線與插槽3.1 provide/inject跨層通信的輕量通道但要注意響應(yīng)式當(dāng)組件層級(jí)變深比如從頁(yè)面?zhèn)鞯綄O組件中間每一層都得拿props透?jìng)饕槐榇a會(huì)變得非常啰嗦。Vue提供了一套跨層傳遞的機(jī)制父組件用provide提供數(shù)據(jù)后代組件用inject注入。中間那些組件不需要知道這件事數(shù)據(jù)直接穿透層級(jí)。!-- 父級(jí)組件 -- script setup import { provide, ref } from vue; const cartCount ref(0); provide(cartCount, cartCount); /script!-- 孫級(jí)組件 -- script setup import { inject } from vue; const cartCount inject(cartCount); /script但這里有個(gè)真實(shí)的坑provide的值如果是普通變量注入后它不是響應(yīng)式的。也就是說(shuō)父組件里改了cartCount子組件注入的那個(gè)值不會(huì)跟著變。想要響應(yīng)式必須主動(dòng)包一層ref或reactive。這也是provide/inject最容易讓人困惑的地方官方文檔說(shuō)得不太顯眼實(shí)際遇到時(shí)排查半天的也不在少數(shù)。注入時(shí)還有個(gè)細(xì)節(jié)值得注意inject(cartCount, defaultValue)的第二個(gè)參數(shù)是默認(rèn)值可以避免父級(jí)還沒(méi)提供數(shù)據(jù)時(shí)子組件拿到undefined。但如果你的子組件未來(lái)可能需要被多個(gè)不同的父組件復(fù)用各自父組件提供的字段名最好不要沖突。項(xiàng)目大了以后provide用的鍵名建議統(tǒng)一整理到一個(gè)常量文件里避免散落各處導(dǎo)致的重名覆蓋問(wèn)題。3.2 事件總線曾經(jīng)的紅人如今慎用早期Vue 2時(shí)代很多項(xiàng)目喜歡用事件總線來(lái)做跨組件通信核心就是全局的$emit和$on。到了Vue 3官方把$on、$off這些移除了事件總線需要自己借助第三方庫(kù)來(lái)實(shí)現(xiàn)比如mitt就是很輕量的選擇npm install mittimport mitt from mitt; const emitter mitt(); // A組件里發(fā)送 emitter.emit(toast-message, 庫(kù)存不足); // B組件里接收 emitter.on(toast-message, (msg) { showToast(msg); });坦白說(shuō)我不太推薦在新項(xiàng)目里把事件總線當(dāng)成主力方案。它確實(shí)很短平快兩個(gè)毫無(wú)嵌套關(guān)系的組件也能互相通但帶來(lái)的問(wèn)題更明顯事件滿天飛你很難搜索代碼弄清楚誰(shuí)觸發(fā)了誰(shuí)狀態(tài)被隱式地分散在各個(gè)回調(diào)里運(yùn)行順序也不可控。如果你只是在處理極少數(shù)臨時(shí)性的跨組件通知比如某個(gè)全局彈窗要關(guān)閉、某個(gè)菜單要展開用事件總線其實(shí)無(wú)傷大雅。但一旦核心業(yè)務(wù)數(shù)據(jù)也靠事件總線來(lái)流轉(zhuǎn)項(xiàng)目會(huì)迅速變得像一個(gè)沒(méi)有走線的電路板出問(wèn)題時(shí)無(wú)從下手。我見過(guò)一個(gè)老項(xiàng)目整個(gè)應(yīng)用里散布著上百個(gè)事件監(jiān)聽后來(lái)重構(gòu)時(shí)不得不把所有on全部列出來(lái)逐一清理。這種事情真的很折磨人。所以我的建議是能用props和emit解決的就別用事件總線跨層數(shù)據(jù)共享優(yōu)先provide/inject需要在共享狀態(tài)基礎(chǔ)上做復(fù)雜邏輯的直接上狀態(tài)管理。3.3 作用域插槽把視圖結(jié)構(gòu)也當(dāng)作通信通道插槽看起來(lái)只跟布局有關(guān)但作用域插槽其實(shí)是一種很有意思的通信方式。父組件通過(guò)插槽傳進(jìn)來(lái)的是模板同時(shí)子組件可以把數(shù)據(jù)通過(guò)slot props回傳給這段模板使用。典型場(chǎng)景是設(shè)計(jì)師想要一個(gè)完全自定義的表格單元格內(nèi)容通用表格組件本身不知道每列要渲染成什么。!-- 子組件 DataTable.vue -- template div v-forrow in rows :keyrow.id slot namecell :rowrow :columncolumn / /div /template!-- 父組件使用 -- template data-table :rowsrows template #cell{ row } span classhighlight{{ row.money }}/span /template /data-table /template在這個(gè)例子里子組件把row數(shù)據(jù)交給父組件的模板使用父組件又通過(guò)插槽內(nèi)容決定怎么渲染。信息的流向和props其實(shí)是反過(guò)來(lái)的。這種通信方式天然適合做以復(fù)用模板結(jié)構(gòu)為核心的組件庫(kù)比如表格、列表、表單容器。你要判斷的場(chǎng)景是外層需要借用內(nèi)層的某部分?jǐn)?shù)據(jù)來(lái)定制視圖同時(shí)又不希望把定制邏輯寫死在子組件里。插槽通信雖然靈活代價(jià)是模板結(jié)構(gòu)的抽象成本會(huì)高一點(diǎn)。項(xiàng)目里如果只有一兩個(gè)地方需要定制我通常還是老老實(shí)實(shí)寫props和emit當(dāng)組件的通用性和擴(kuò)展性價(jià)值明顯大于理解成本時(shí)才值得上插槽。4. 全局狀態(tài)管理當(dāng)通信開始牽引全局4.1 先說(shuō)設(shè)計(jì)再談工具全局狀態(tài)不是通信的銀彈前面講的手段都是局部通信。當(dāng)同一個(gè)狀態(tài)被頁(yè)面上很多個(gè)角落共享而且組件之間的嵌套關(guān)系又很復(fù)雜時(shí)你可能會(huì)想到全局狀態(tài)管理。在Vue生態(tài)里現(xiàn)在是Pinia的天下它比Vuex更簡(jiǎn)潔對(duì)TypeScript的支持也好很多核心概念還是繞不開那兩件事單一數(shù)據(jù)源和單向數(shù)據(jù)流。一定要想清楚的一點(diǎn)是全局狀態(tài)管理解決的不只是傳數(shù)據(jù)的問(wèn)題它解決的還有這些數(shù)據(jù)應(yīng)該由誰(shuí)統(tǒng)一維護(hù)、統(tǒng)一修改的問(wèn)題。把狀態(tài)放進(jìn)store之后所有組件都從一個(gè)地方讀取所有修改都要通過(guò)store里的action進(jìn)行。這樣通信的路徑一下子從很多條線變成了一條主線組件到action再到state再回到組件。代價(jià)也很實(shí)在store一旦膨脹就會(huì)變成一個(gè)大雜燴。所以我的原則是只有當(dāng)通信鏈路真的復(fù)雜到props補(bǔ)丁式傳遞都難以維護(hù)的時(shí)候才引入全局狀態(tài)。一些看起來(lái)是全局的數(shù)據(jù)比如當(dāng)前主題色、用戶登錄態(tài)確實(shí)適合放store但某個(gè)頁(yè)面內(nèi)部的交互狀態(tài)最好還是留在頁(yè)面組件內(nèi)部。把它們?nèi)咳只粫?huì)讓越來(lái)越多的地方互相牽連。4.2 用Pinia重構(gòu)購(gòu)物車鏈路繼續(xù)用購(gòu)物車?yán)?。如果把加?gòu)這個(gè)動(dòng)作交給Pinia整個(gè)通信鏈路會(huì)變成按鈕組件調(diào)用store里的addCart方法列表頁(yè)讀取store里的cartCount角標(biāo)組件也讀取cartCount。不用再一級(jí)級(jí)一層層地傳。store的代碼大概是這樣的// stores/cart.js import { defineStore } from pinia; export const useCartStore defineStore(cart, { state: () ({ items: [], }), getters: { cartCount: (state) state.items.reduce((sum, item) sum item.quantity, 0), }, actions: { addCart(product) { const existing this.items.find((item) item.id product.id); if (existing) { existing.quantity 1; } else { this.items.push({ ...product, quantity: 1 }); } }, }, });組件里使用時(shí)注意一個(gè)細(xì)節(jié)從store里解構(gòu)出來(lái)的state如果不做處理會(huì)丟失響應(yīng)性。在Pinia中官方推薦用storeToRefsimport { storeToRefs } from pinia; import { useCartStore } from /stores/cart; const store useCartStore(); const { cartCount } storeToRefs(store);用storeToRefs取出來(lái)后cartCount才是響應(yīng)式的模板里綁定它才能實(shí)時(shí)更新。這個(gè)細(xì)節(jié)經(jīng)常被初學(xué)者忽略結(jié)果是頁(yè)面數(shù)據(jù)不刷新最后抓到頭發(fā)都要掉了。直接調(diào)用store.addCart方法則沒(méi)有這個(gè)問(wèn)題因?yàn)榉椒ū緛?lái)就是掛在store實(shí)例上的。4.3 什么時(shí)候別用全局狀態(tài)本地狀態(tài)被過(guò)度全局化的危害最后給個(gè)明確的判斷標(biāo)準(zhǔn)。如果你發(fā)現(xiàn)一個(gè)state只在某一個(gè)組件內(nèi)部使用或者它影響的組件不超過(guò)一兩個(gè)那它就不應(yīng)該出現(xiàn)在全局store里。過(guò)度全局化會(huì)導(dǎo)致幾個(gè)現(xiàn)象組件為了讀取某個(gè)數(shù)據(jù)不得不在模板里寫一大串store引用修改一個(gè)本地交互狀態(tài)還要經(jīng)過(guò)action的審批流程組件在復(fù)用時(shí)會(huì)默默依賴store里的某個(gè)字段移植到另一個(gè)項(xiàng)目就崩了。我自己的處理方式是先分三層組件內(nèi)部狀態(tài)用ref和computed跨組件但范圍可控的用props和emit只有真正會(huì)被多個(gè)隔離角落共享的狀態(tài)才進(jìn)store。通常情況下頁(yè)面數(shù)據(jù)的共享通過(guò)props和組件拆分就能解決很多中小項(xiàng)目的store最后其實(shí)只需要放用戶信息、權(quán)限、主題這類基礎(chǔ)設(shè)施級(jí)的數(shù)據(jù)就夠了。組合式函數(shù)也值得提一句如果你只是想共享一段邏輯而不是共享一份狀態(tài)用自定義hook會(huì)更合適。比如useDebounce、useRequest它們更像是邏輯復(fù)用工具跟狀態(tài)通信的目標(biāo)不同別混為一談。5. 通信方案同屏對(duì)照與故障排查5.1 通信方式速查表到了這個(gè)階段把工具都聊完了該給一張能直接對(duì)照的表了方便你在寫代碼前快速確定用哪個(gè)方案。這只是最常見的選型參考不代表絕對(duì)真理關(guān)鍵還是看你的具體場(chǎng)景。通信場(chǎng)景推薦方案核心API/思路注意點(diǎn)父子傳值props下行defineProps不可在子組件修改props子向父通信事件上行defineEmits emit事件名統(tǒng)一kebab-case兄弟通信提升到共同父組件父組件中轉(zhuǎn)的狀態(tài)避免跨層直接互相引用跨層少量共享provide/injectprovide inject值需要包ref/reactive才能響應(yīng)通用模板定制作用域插槽具名插槽 slot props適合表格/列表類組件定制跨組件表單值v-modelupdate:modelValue適合一個(gè)值的同步復(fù)雜對(duì)象謹(jǐn)慎多個(gè)隔離角共享全局狀態(tài)管理Pinia狀態(tài)被徹底全局化前先做范圍評(píng)估零散臨時(shí)通知事件總線mitt慎用核心業(yè)務(wù)別用它這幾條結(jié)論看著簡(jiǎn)單都是我寫過(guò)不少項(xiàng)目后總結(jié)出來(lái)的。放在項(xiàng)目里最要命的地方其實(shí)不是選錯(cuò)方案而是同一種通信場(chǎng)景在不同頁(yè)面里用了不同方案搞得代碼風(fēng)格完全不一致。我建議團(tuán)隊(duì)內(nèi)部統(tǒng)一一套選型規(guī)范至少保證相同的關(guān)系類型走相同的方案。5.2 高頻問(wèn)題與排查路徑多數(shù)時(shí)候組件間通信出問(wèn)題不是沒(méi)通而是改了數(shù)據(jù)界面沒(méi)反應(yīng)。我按自己實(shí)際排查的順序整理幾條常見原因做成一張速查表現(xiàn)象可能原因排查方向props傳了但子組件不更新父組件傳的是普通變量而不是響應(yīng)式狀態(tài)檢查父組件原數(shù)據(jù)是否用ref/reactive包裹props改了但視圖不更新子組件直接修改了props里的對(duì)象屬性全局搜索對(duì)props字段的賦值操作emit好像沒(méi)觸發(fā)事件名大小寫不匹配或監(jiān)聽綁錯(cuò)元素對(duì)比emit名和模板事件名用DevTools查看inject得到undefined父組件沒(méi)有provide同名數(shù)據(jù)檢查provide的鍵名是否一致是否加了默認(rèn)值inject的值不響應(yīng)provide傳的是普通對(duì)象/數(shù)組未包ref/reactive改成ref或reactive后重新注入store里改了頁(yè)面不動(dòng)解構(gòu)state時(shí)丟失響應(yīng)性用storeToRefs包裹再解構(gòu)事件總線消息丟失監(jiān)聽組件在emit之后才掛載監(jiān)聽梳理組件生命周期避免對(duì)時(shí)序的依賴這些小問(wèn)題里我認(rèn)為props被直接修改是最隱蔽的一種。它不會(huì)立刻報(bào)錯(cuò)而是會(huì)在某個(gè)看似無(wú)關(guān)的改動(dòng)后突然冒出詭異行為排查成本非常高昂。所以不管項(xiàng)目大小我都建議約定一條鐵律所有props都按只讀處理誰(shuí)要改數(shù)據(jù)誰(shuí)就提事件。5.3 我在真實(shí)項(xiàng)目里的踩坑與重構(gòu)實(shí)錄之前維護(hù)過(guò)一個(gè)后臺(tái)管理系統(tǒng)里面有個(gè)權(quán)限樹組件初始版本就是典型的props加emit一層層往上拋事件。權(quán)限樹本身是嵌套的數(shù)據(jù)要從最內(nèi)層的子節(jié)點(diǎn)一直冒泡到頁(yè)面根組件中間經(jīng)歷四五層。改需求時(shí)每次都要沿著事件鏈從下往上捋一遍非常痛。后來(lái)我把權(quán)限樹的數(shù)據(jù)訪問(wèn)改成provide/inject樹組件內(nèi)部通過(guò)inject直接獲取到權(quán)限操作方法跨層透?jìng)鞯氖录幌伦由倭撕芏鄬?。?dāng)然代價(jià)是樹組件的復(fù)用不再那么干凈它隱式依賴了外層提供的接口。當(dāng)時(shí)權(quán)衡下來(lái)這種依賴發(fā)生在同一個(gè)模塊內(nèi)部是可接受的。另一個(gè)印象更深的項(xiàng)目是庫(kù)存統(tǒng)計(jì)頁(yè)。一開始所有篩選條件、分頁(yè)、排序都放在store里結(jié)果頁(yè)面組件代碼越寫越厚store里的字段越來(lái)越多很多頁(yè)面和store的文件互相引用亂成一團(tuán)。后來(lái)我做重構(gòu)把只服務(wù)當(dāng)前頁(yè)面狀態(tài)的篩選和分頁(yè)全部收回頁(yè)面組件內(nèi)部store只保留了跨頁(yè)面共享的全局?jǐn)?shù)據(jù)。改完之后頁(yè)面的可讀性明顯提升排查路徑也短了很多。從這兩個(gè)項(xiàng)目中我經(jīng)常提醒自己的是組件間通信的方案沒(méi)有最好只有最合適。合適的標(biāo)準(zhǔn)不是用到了多高級(jí)的API而是出問(wèn)題時(shí)你能在三分鐘內(nèi)定位到那條數(shù)據(jù)鏈路。大多數(shù)情況下越樸素的手段越可靠狀態(tài)管理這類重型工具要留給真正值得它出場(chǎng)的場(chǎng)景。寫到最后我真的覺得組件間通信最核心的那件事并不在某個(gè)API本身。你先要知道數(shù)據(jù)歸誰(shuí)然后決定它怎么流動(dòng)最后再來(lái)選API。順序反過(guò)來(lái)寫出來(lái)的代碼往往就是表面上能跑改起來(lái)卻處處受氣。這幾年我?guī)е@個(gè)思路處理了各式各樣的組件通信問(wèn)題一次比一次輕松。希望這篇內(nèi)容能幫你把這條路也走直一些。