1. 組件通信全景圖別再做只會(huì)“傳參”的搬運(yùn)工組件通信這件事說(shuō)大不大說(shuō)小不小。剛接觸React那會(huì)兒我一度覺(jué)得組件通信不就是父組件往子組件丟幾個(gè)props子組件回調(diào)一下父組件傳入的函數(shù)嘛。直到后來(lái)維護(hù)一個(gè)中大型后臺(tái)項(xiàng)目幾十個(gè)組件嵌套五六層狀態(tài)散落得到處都是我才意識(shí)到組件通信本質(zhì)上是在解決“數(shù)據(jù)往哪里放、怎么流動(dòng)、誰(shuí)該擁有什么數(shù)據(jù)”的架構(gòu)問(wèn)題。可以說(shuō)搞懂了組件通信React才算真正入門。這篇文章想聊透React組件通信這件事。從最基礎(chǔ)的父?jìng)髯?、子傳父到高階的Context、Ref通信、全局狀態(tài)管理再到面試高頻題和線上排查經(jīng)驗(yàn)我會(huì)把我在真實(shí)項(xiàng)目里踩過(guò)的坑、總結(jié)的經(jīng)驗(yàn)、驗(yàn)證過(guò)可行的方案一并寫出來(lái)。適合剛學(xué)完React基礎(chǔ)、準(zhǔn)備找前端工作的同學(xué)也適合已經(jīng)工作但想系統(tǒng)梳理組件通信方案的開發(fā)者。先給一個(gè)整體認(rèn)知框架。組件通信不是靠某一種技術(shù)包打天下的而是按場(chǎng)景選方案的組合拳。通信方向無(wú)非三種自上而下父?jìng)髯?、自下而上子傳父、水?跨層級(jí)兄弟間、任意組件間。以我實(shí)際項(xiàng)目經(jīng)驗(yàn)來(lái)看90%的通信需求集中在“自上而下”和“自下而上”這兩類剩下10%的復(fù)雜跨層級(jí)通信才會(huì)動(dòng)用Context或全局狀態(tài)庫(kù)。但同樣是父子通信寫法上也有講究。有的同學(xué)喜歡把setState一層層往下傳傳了四五層之后子組件改一個(gè)輸入框整條鏈路上的組件全部重新渲染頁(yè)面卡成PPT。這不是React的問(wèn)題是數(shù)據(jù)流沒(méi)設(shè)計(jì)好。我后面會(huì)講清楚怎么避免這種“傳遞地獄”。1.1 團(tuán)隊(duì)協(xié)作中的通用標(biāo)準(zhǔn)是“約束”其實(shí)組件通信背后最大的痛點(diǎn)不是“能不能傳”而是“怎么傳才規(guī)范”。團(tuán)隊(duì)里五個(gè)人寫代碼一個(gè)人習(xí)慣用props層層傳遞另一個(gè)人喜歡把Context當(dāng)全局變量用第三個(gè)人干脆裝了Redux把所有數(shù)據(jù)都塞進(jìn)去結(jié)果代碼評(píng)審的時(shí)候誰(shuí)都不知道某個(gè)數(shù)據(jù)到底從哪兒來(lái)、改哪兒會(huì)觸發(fā)什么連鎖反應(yīng)。所以我一直主張團(tuán)隊(duì)內(nèi)部必須有一個(gè)組件通信的“通用標(biāo)準(zhǔn)”。標(biāo)準(zhǔn)不是限制你的技術(shù)選型而是規(guī)定什么場(chǎng)景用什么方案讓代碼可預(yù)測(cè)、可追溯。我見過(guò)太多項(xiàng)目死在“自由發(fā)揮”上。哪怕你定的標(biāo)準(zhǔn)只是“父子通信一律用props跨三層以上的狀態(tài)統(tǒng)一放Context涉及到登錄態(tài)之類的全局?jǐn)?shù)據(jù)才允許用狀態(tài)庫(kù)”也比毫無(wú)章法強(qiáng)得多。因?yàn)楫?dāng)代碼量上來(lái)以后可讀性和可維護(hù)性遠(yuǎn)比那一點(diǎn)“靈活性”重要。1.2 參考其他框架的通信設(shè)計(jì)思路順便聊聊React和其他框架的對(duì)比因?yàn)槊嬖嚴(yán)锝?jīng)常被問(wèn)到也幫助理解React通信設(shè)計(jì)背后的取舍。Vue的組件通信里有一個(gè)很核心的概念叫“單向數(shù)據(jù)流”父組件通過(guò)props把數(shù)據(jù)傳給子組件子組件通過(guò)emit事件通知父組件修改數(shù)據(jù)。這一點(diǎn)和React的“狀態(tài)由父組件持有子組件通過(guò)回調(diào)上報(bào)”其實(shí)是同構(gòu)的思想只不過(guò)Vue把它變成了框架層面的語(yǔ)法糖而React更偏向JavaScript原生思維。Flutter的組件通信思路也類似構(gòu)造函數(shù)傳參是主流InheritedWidget承擔(dān)了類似Context跨層級(jí)共享的職責(zé)。你會(huì)發(fā)現(xiàn)但凡做得好的UI框架底層通信思想是相通的數(shù)據(jù)歸誰(shuí)管誰(shuí)就能改別人想改得通過(guò)約定的通道。React不比別的框架高級(jí)但它把這種約定做成了靈活度最高的組合方式這也正是它生態(tài)豐富、經(jīng)久不衰的原因。2. 父子通信最常用也最容易被寫爛的模式如果說(shuō)React是一座大樓那父子通信就是鋼筋混凝土。它普通到幾乎不需要解釋卻又重要到一不留神就會(huì)寫出難以維護(hù)的代碼。這一章我們就把父?jìng)髯雍妥觽鞲笍氐字v透從原理到實(shí)操細(xì)節(jié)全部過(guò)一遍。2.1 父?jìng)髯觩rops不只是“傳值”那么簡(jiǎn)單父組件給子組件傳數(shù)據(jù)最直白的寫法就是給子組件標(biāo)簽上加屬性// 父組件 function Dashboard() { const [userInfo, setUserInfo] useState({ name: 張三, role: admin }); return UserCard user{userInfo} /; } // 子組件 function UserCard({ user }) { return ( div h3{user.name}/h3 p{user.role}/p /div ); }這段代碼看起來(lái)毫無(wú)難度但我要提醒三個(gè)極易被忽略的細(xì)節(jié)。第一props是只讀的。子組件絕對(duì)不能直接改props里的對(duì)象。我見過(guò)新人直接在子組件里寫user.name 李四雖然這個(gè)操作能生效但React官方明確反對(duì)這種寫法因?yàn)樗茐牧藛蜗驍?shù)據(jù)流。以后任何人接手都不知道這個(gè)name為什么變了排查問(wèn)題的時(shí)候直接吐血。正確的做法是如果子組件要維護(hù)自己的展示狀態(tài)先拷貝到本地state如果要改父組件的數(shù)據(jù)調(diào)用父組件傳下來(lái)的回調(diào)函數(shù)。第二props會(huì)觸發(fā)更新。父組件重新渲染時(shí)子組件的props會(huì)重新計(jì)算。但如果傳的是內(nèi)聯(lián)對(duì)象比如UserCard user{{ name: 張三, role: admin }} /那么父組件每次渲染這個(gè)對(duì)象都是新引用子組件即使什么都不變也會(huì)跟著渲染。性能敏感的場(chǎng)景下這種寫法是隱形殺手。第三children也是props。組件標(biāo)簽內(nèi)部嵌套的內(nèi)容實(shí)際上是props.children。很多復(fù)雜組件通過(guò)children做插槽式設(shè)計(jì)這在封裝通用UI組件時(shí)極其有用。比如Cardp內(nèi)容/p/CardCard內(nèi)部拿到的是渲染好的標(biāo)簽節(jié)點(diǎn)靈活度遠(yuǎn)高于直接傳字符串。2.2 子傳父回調(diào)函數(shù)的本質(zhì)是把“修改權(quán)”交還父組件子組件往父組件傳數(shù)據(jù)核心手法是父組件提前準(zhǔn)備好一個(gè)修改自身狀態(tài)的函數(shù)把它通過(guò)props傳給子組件子組件在合適的時(shí)機(jī)調(diào)用它。// 父組件 function SearchPage() { const [keyword, setKeyword] useState(); const handleSearch (value) { setKeyword(value); // 這里還可以做搜索請(qǐng)求、埋點(diǎn)上報(bào)等邏輯 }; return SearchInput onSearch{handleSearch} /; } // 子組件 function SearchInput({ onSearch }) { const [text, setText] useState(); const submit () { onSearch(text.trim()); }; return ( div input value{text} onChange{(e) setText(e.target.value)} / button onClick{submit}搜索/button /div ); }很多人一開始不理解為什么不直接在子組件里操作父組件的狀態(tài)。你用回調(diào)的方式想一下父組件把handleSearch傳給子組件子組件只是在合適的時(shí)機(jī)“通知”父組件真正的狀態(tài)變更還是發(fā)生在父組件里。這樣一來(lái)數(shù)據(jù)的持有者和修改者是同一方邏輯不會(huì)分裂。這就是React社區(qū)常說(shuō)的“狀態(tài)提升”也是面試中“子傳父”相關(guān)問(wèn)題的核心。我再補(bǔ)充一個(gè)衍生知識(shí)點(diǎn)如果子組件要傳多個(gè)值不要寫多個(gè)回調(diào)props那樣接口會(huì)很啰嗦?？梢园褦?shù)據(jù)打包成對(duì)象一次回調(diào)傳出去父組件自行解構(gòu)使用。接口設(shè)計(jì)得清爽代碼自然好維護(hù)。2.3 不可變數(shù)據(jù)React組件通信的高壓線聊到props傳數(shù)據(jù)的本質(zhì)就繞不開不可變數(shù)據(jù)Immutability。React判斷一個(gè)組件要不要重新渲染默認(rèn)用的是淺比較Object.is。如果父組件把一個(gè)數(shù)組傳給子組件子組件內(nèi)部直接arr.push(item)父組件的引用沒(méi)有變化子組件很可能不會(huì)正確感知到數(shù)據(jù)更新。所以只要是跨組件傳遞的數(shù)據(jù)想更新它的時(shí)候必須返回一個(gè)新引用。比如// 錯(cuò)誤直接修改原數(shù)組 const handleAdd () { list.push(newItem); setList(list); } // 正確返回新數(shù)組 const handleAdd () { setList([...list, newItem]); }這個(gè)坑可以說(shuō)是新手八大錯(cuò)誤之首。我在代碼評(píng)審時(shí)幾乎每個(gè)月都會(huì)見到一次。把“所有修改都得返回新值”刻進(jìn)腦子里組件通信的很多bug自然消失。這一章的實(shí)操心得濃縮成一句話父子通信的根本原則是“誰(shuí)擁有數(shù)據(jù)誰(shuí)負(fù)責(zé)修改”。父組件擁有數(shù)據(jù)傳值和回調(diào)子組件展示數(shù)據(jù)通過(guò)回調(diào)發(fā)起修改請(qǐng)求。守住這條原則你的代碼不會(huì)亂到哪里去。3. 跨層級(jí)通信Context、Ref與事件匯聚的三重選擇項(xiàng)目中總會(huì)遇到這樣的場(chǎng)景當(dāng)前用戶信息、主題色、語(yǔ)言包這種全局?jǐn)?shù)據(jù)被幾十個(gè)組件用到。如果還靠props一層層往下傳中間那些其實(shí)不需要這個(gè)數(shù)據(jù)的組件也得接一遍又丑又難維護(hù)。這時(shí)候就需要跨層級(jí)通信方案上場(chǎng)。3.1 Context把數(shù)據(jù)直接“注入”深層次組件React官方的Context API就是為了解決“逐層傳遞”的痛點(diǎn)。它允許你在頂層創(chuàng)建一個(gè)“數(shù)據(jù)源”任何層級(jí)的子組件都可以直接訂閱。const ThemeContext React.createContext({ theme: light, toggleTheme: () {} }); function App() { const [theme, setTheme] useState(light); return ( ThemeContext.Provider value{{ theme, toggleTheme: () setTheme(theme light ? dark : light) }} Layout / /ThemeContext.Provider ); } // 深層子組件直接消費(fèi) function ThemeToggleButton() { const { theme, toggleTheme } React.useContext(ThemeContext); return button onClick{toggleTheme}{theme}/button; }Context用起來(lái)爽但有兩個(gè)被吐槽最多的副作用。第一個(gè)是性能問(wèn)題。Provider的value一變所有消費(fèi)這個(gè)Context的組件都會(huì)重新渲染哪怕它們只用了value中的某一個(gè)小字段。針對(duì)這個(gè)我總結(jié)了兩個(gè)優(yōu)化手段把頻繁變化的字段拆成獨(dú)立的Context比如ThemeContext只管主題UserContext只管用戶信息讓不同數(shù)據(jù)各歸各的Context。在消費(fèi)組件里用useMemo包一層把Context的value拆解后進(jìn)行更精細(xì)的比較和控制。第二個(gè)是濫用問(wèn)題。有些同學(xué)嫌props麻煩把一堆業(yè)務(wù)數(shù)據(jù)全塞進(jìn)Context結(jié)果整個(gè)項(xiàng)目變成“全局變量地獄”調(diào)試起來(lái)根本不知道值是什么時(shí)候被誰(shuí)改的。我的建議是Context適合“低頻更新”的跨層級(jí)共享數(shù)據(jù)比如主題、語(yǔ)言、登錄狀態(tài)。如果是高頻變化且邏輯復(fù)雜的數(shù)據(jù)請(qǐng)考慮全局狀態(tài)管理庫(kù)。3.2 ForwardRef與useImperativeHandle把命令式操作變成組件通信的一種補(bǔ)充React整體的設(shè)計(jì)哲學(xué)是“聲明式”但總有些場(chǎng)景不得不寫“命令式”代碼比如手動(dòng)聚焦一個(gè)輸入框、觸發(fā)子組件內(nèi)部的方法、讀取子組件某個(gè)DOM節(jié)點(diǎn)的尺寸。React為此提供了forwardRef和useImperativeHandle。const ChildInput React.forwardRef(function ChildInput(props, ref) { const inputRef useRef(null); useImperativeHandle(ref, () ({ focusInput: () { inputRef.current?.focus(); }, getValue: () inputRef.current?.value || })); return input ref{inputRef} {...props} /; }); // 父組件 function Parent() { const childRef useRef(null); const handleClick () { childRef.current.focusInput(); }; return ( ChildInput ref{childRef} / button onClick{handleClick}聚焦子組件輸入框/button / ); }這段代碼值得注意的細(xì)節(jié)是useImperativeHandle里返回的對(duì)象就是父組件通過(guò)ref.current能拿到的全部能力。它有點(diǎn)像一個(gè)“公開接口”只暴露你想暴露的方法內(nèi)部細(xì)節(jié)全部隱藏。我用這個(gè)方案封裝過(guò)編輯器、上傳組件、復(fù)雜表單校驗(yàn)邏輯體驗(yàn)都不錯(cuò)。但我也要說(shuō)清楚它只適合“父子之間”的通信跨多層、跨分支就別硬用ref了代碼會(huì)變成蜘蛛網(wǎng)。在面試中能講清楚“什么時(shí)候用ref通信什么是命令式和聲明式的邊界”是一個(gè)非常加分的亮點(diǎn)。3.3 事件總線為什么在React里不受歡迎Vue時(shí)代很多人習(xí)慣用EventBus做跨組件通信發(fā)布訂閱一套搞定。到了React里EventBus仍然是可用的但React官方社區(qū)并不推薦它作為主要通信手段原因是它繞開了React的數(shù)據(jù)流體系事件一旦觸發(fā)你無(wú)法從React DevTools里追蹤數(shù)據(jù)流。不過(guò)我還是要給出EventBus的適用場(chǎng)景跨iframe通信、微前端子應(yīng)用間通信。這些場(chǎng)景天然存在于React外部用事件發(fā)布訂閱反而是最干凈的方式。除此之外建議優(yōu)先使用Context或狀態(tài)管理庫(kù)保持單向數(shù)據(jù)流的一致性和可調(diào)試性。3.4 三種跨層級(jí)方案的選型決策表我遇到過(guò)很多人在群里問(wèn)“跨層級(jí)到底選Context還是Redux”這是個(gè)好問(wèn)題但從來(lái)都不是“越強(qiáng)勢(shì)越好”。我根據(jù)自己的經(jīng)驗(yàn)整理了一個(gè)決策表方案適用場(chǎng)景優(yōu)勢(shì)劣勢(shì)數(shù)據(jù)調(diào)試難度Context低頻更新的全局?jǐn)?shù)據(jù)主題、語(yǔ)言、登錄態(tài)內(nèi)置API零依賴代碼量小value變化時(shí)所有消費(fèi)者重渲染中Ref 通信父子之間的命令式操作精準(zhǔn)控制DOM不觸發(fā)無(wú)謂渲染僅限于父子場(chǎng)景低事件總線iframe、微前端、跨應(yīng)用邊界跨域穿透力強(qiáng)解耦徹底不好追蹤來(lái)源易濫用高別看到“高”就害怕。事件總線只要?jiǎng)澏ê眠吔缰辉诳鐟?yīng)用場(chǎng)景使用它反而是最合適的。通信方案的選擇原則永遠(yuǎn)是“夠用且好維護(hù)”而不是“功能最強(qiáng)”。4. 全局狀態(tài)管理與服務(wù)端通信大項(xiàng)目的通信架構(gòu)思考當(dāng)項(xiàng)目體量繼續(xù)膨脹單純靠Context已經(jīng)控制不住狀態(tài)的時(shí)候就該認(rèn)真考慮“全局狀態(tài)管理”這個(gè)層級(jí)了。這一章聊聊全局狀態(tài)庫(kù)的選型、服務(wù)端數(shù)據(jù)通信以及怎么把組件通信放在真實(shí)的復(fù)雜業(yè)務(wù)場(chǎng)景里落地。4.1 什么時(shí)候該上全局狀態(tài)管理我的標(biāo)準(zhǔn)很簡(jiǎn)單如果一份數(shù)據(jù)被三個(gè)以上不相關(guān)的組件共享同時(shí)數(shù)據(jù)更新的邏輯比較復(fù)雜比如設(shè)計(jì)到異步請(qǐng)求、持久化、聯(lián)動(dòng)計(jì)算那就應(yīng)該考慮引入全局狀態(tài)管理庫(kù)。如果只是兩三個(gè)組件之間傳值老老實(shí)實(shí)用props和Context引入Redux只會(huì)白白增加概念負(fù)擔(dān)和樣板代碼。坦白講Redux的學(xué)習(xí)曲線讓很多新人望而卻步它的Action、Reducer、Dispatch這些概念是有一定門檻的。但理解了你會(huì)發(fā)現(xiàn)Redux做的事情和組件通信的底層邏輯完全一致你把狀態(tài)收斂到一個(gè)全局store里任何組件想要修改數(shù)據(jù)都通過(guò)dispatch發(fā)出指令reducer負(fù)責(zé)根據(jù)指令計(jì)算新狀態(tài)。這種嚴(yán)格的單向數(shù)據(jù)流保證了任何一次數(shù)據(jù)變更都是可追蹤、可回放的。4.2 Zustand與Jotai新一代狀態(tài)庫(kù)的通信思路這幾年我越來(lái)越喜歡Zustand這樣輕量級(jí)的狀態(tài)庫(kù)寫起來(lái)比Redux舒服太多import { create } from zustand; const useStore create((set) ({ user: null, login: (userInfo) set({ user: userInfo }), logout: () set({ user: null }), })); // 任意組件中讀取狀態(tài) function UserAvatar() { const user useStore((state) state.user); return img src{user?.avatar} altavatar /; }Zustand最好的地方是它的選擇器機(jī)制——組件可以精細(xì)訂閱自己關(guān)心的那部分狀態(tài)。比如user變了但theme沒(méi)變訂閱theme的組件不會(huì)重新渲染。這是Context方案很難做到的。Jotai的思路則更“原子化”把每個(gè)狀態(tài)拆分到極細(xì)粒度。它適合那種狀態(tài)零散、組合關(guān)系復(fù)雜的場(chǎng)景。說(shuō)到底狀態(tài)庫(kù)只是工具真正決定項(xiàng)目上限的還是你對(duì)數(shù)據(jù)模型和通信邊界的理解。狀態(tài)庫(kù)選型可以爭(zhēng)論但“統(tǒng)一標(biāo)準(zhǔn)、限定使用范圍”這兩件事團(tuán)隊(duì)內(nèi)部必須達(dá)成共識(shí)。4.3 服務(wù)端通信SSE/WebSocket與組件數(shù)據(jù)的聯(lián)動(dòng)組件通信不只發(fā)生在組件之間還發(fā)生在組件和服務(wù)端之間。很多實(shí)時(shí)功能比如文件上傳進(jìn)度、在線聊天、行情推送都需要通過(guò)SSE或WebSocket把服務(wù)端數(shù)據(jù)源源不斷地推進(jìn)客戶端。我實(shí)際做過(guò)的項(xiàng)目里有一個(gè)需求是監(jiān)聽服務(wù)端某個(gè)文件的變化實(shí)時(shí)把變更狀態(tài)推送給前端頁(yè)面。最初我們用輪詢接口每隔幾秒請(qǐng)求一次浪費(fèi)后端資源不說(shuō)推送還有延遲。后來(lái)改成長(zhǎng)連接方案前端建立起連接服務(wù)端有變化就主動(dòng)推消息// 偽代碼SSE建立連接并訂閱消息 useEffect(() { const eventSource new EventSource(/api/file/change-stream); eventSource.onmessage (event) { // 把服務(wù)端推送的數(shù)據(jù)寫入store useStore.getState().updateFileStatus(JSON.parse(event.data)); }; return () { eventSource.close(); }; }, []);這種“服務(wù)端事件驅(qū)動(dòng)組件更新”的模式本質(zhì)上也是組件通信的一種變體。你需要做的只是把onmessage回調(diào)里的數(shù)據(jù)“寫”進(jìn)當(dāng)前組件可感知的狀態(tài)容器里。無(wú)論這個(gè)容器是Context、Zustand還是Redux通信鏈路都是通暢的。我在實(shí)操中最大的感觸是接入SSE/WebSocket的代碼要單獨(dú)封裝成自定義Hook不要在組件里裸寫。否則組件卸載、重新連接、異常重試這些邏輯會(huì)和UI渲染摻在一起想排查都無(wú)從下手。4.4 一個(gè)管理后臺(tái)的通信架構(gòu)示例為了把這些概念串起來(lái)我描述一個(gè)典型的管理后臺(tái)架構(gòu)頁(yè)面A是用戶列表頁(yè)面B是用戶詳情兩個(gè)頁(yè)面都需要讀取“當(dāng)前搜索條件”。全局有一個(gè)userStore保存用戶列表數(shù)據(jù)列表頁(yè)通過(guò)store讀數(shù)據(jù)、發(fā)起搜索詳情頁(yè)通過(guò)store讀列表中的當(dāng)前選中項(xiàng)。主題配置放Context登錄信息放store表單內(nèi)部狀態(tài)用組件本地state。實(shí)時(shí)通知走SSE把消息寫入store后彈提示。這套架構(gòu)里組件通信的邊界非常清晰頁(yè)面內(nèi)部組件靠props和回調(diào)跨頁(yè)面共享數(shù)據(jù)靠store全局配置靠Context外部數(shù)據(jù)靠訂閱。每種通信工具都在自己擅長(zhǎng)的地方發(fā)揮作用代碼不會(huì)亂排查問(wèn)題也快。我覺(jué)得這種“架構(gòu)感”才是資深前端和初中級(jí)開發(fā)最明顯的分水嶺。5. 面試高頻題與手寫實(shí)現(xiàn)組件通信在面經(jīng)里的那些坑把組件通信寫成文章的人很多但真正針對(duì)面試場(chǎng)景聊透的少。這一章我結(jié)合自己面試別人和被別人面試的經(jīng)歷整理幾個(gè)最容易暴露水平的問(wèn)題。5.1 八分鐘速查面試考點(diǎn)對(duì)照表面試官考察組件通信很少直接問(wèn)“你用過(guò)哪些通信方式”而是把通信方式藏在真實(shí)場(chǎng)景里。下面這些是我整理的考點(diǎn)對(duì)照表可以幫助你檢查自己的知識(shí)盲區(qū)考點(diǎn)面試常見問(wèn)法考察核心props單向數(shù)據(jù)流子組件能不能直接改props不可變數(shù)據(jù)、受控/非受控組件回調(diào)函數(shù)傳參子傳父的兩種寫法有什么不同狀態(tài)提升、事件機(jī)制受控組件請(qǐng)實(shí)現(xiàn)一個(gè)受控輸入框表單通信、數(shù)據(jù)流閉環(huán)Context優(yōu)化Context會(huì)造成全量渲染嗎如何解決性能優(yōu)化、useMemoref通信父組件怎么主動(dòng)觸發(fā)子組件里的方法forwardRef、useImperativeHandle狀態(tài)管理選型什么場(chǎng)景用Redux什么場(chǎng)景用Context架構(gòu)思維、規(guī)模判斷兄弟組件通信兩個(gè)兄弟組件怎么共享狀態(tài)狀態(tài)提升、Context與狀態(tài)庫(kù)渲染優(yōu)化props不變時(shí)怎么阻止子組件重渲染React.memo、useCallback、useMemo5.2 手寫實(shí)現(xiàn)一個(gè)簡(jiǎn)單的React通信模型面試中經(jīng)常出現(xiàn)“手寫React思路”類的題目比如“不用React你會(huì)怎么實(shí)現(xiàn)一個(gè)最小的組件通信機(jī)制”。這個(gè)問(wèn)題的考察點(diǎn)是你能不能脫離框架談本質(zhì)。我給出一個(gè)極簡(jiǎn)版本用原生JavaScript的發(fā)布訂閱模式實(shí)現(xiàn)跨組件通信的核心思路// 極簡(jiǎn)版發(fā)布訂閱組件通信的底層本質(zhì) class EventEmitter { constructor() { this.events {}; } // 訂閱 subscribe(eventName, callback) { if (!this.events[eventName]) { this.events[eventName] []; } this.events[eventName].push(callback); return () { this.events[eventName] this.events[eventName].filter(cb cb ! callback); }; } // 發(fā)布 emit(eventName, payload) { if (this.events[eventName]) { this.events[eventName].forEach(cb cb(payload)); } } } // 使用示例 const bus new EventEmitter(); // 組件A訂閱主題變化 bus.subscribe(theme:change, (theme) { console.log(主題更新為, theme); }); // 組件B發(fā)布主題變化 bus.emit(theme:change, dark);寫完這段代碼后你再回頭看React的Context、Redux的dispatch乃至Zustand的set方法其實(shí)都是在做類似的事一份共享的數(shù)據(jù)源一個(gè)可訂閱的通知機(jī)制一套修改數(shù)據(jù)的約定。理解了這一層手寫React相關(guān)通信題目的時(shí)候就不會(huì)慌?？蚣懿皇悄Хㄖ皇前训讓訖C(jī)制封裝成了好用的API。5.3 面試中常見的“送命題”解析我經(jīng)常在面試中故意問(wèn)一個(gè)看似很基礎(chǔ)的問(wèn)題“父組件重新渲染子組件一定會(huì)重新渲染嗎”答案是默認(rèn)會(huì)但可以通過(guò)React.memo讓子組件在props不變時(shí)跳過(guò)渲染。這個(gè)問(wèn)題的分?jǐn)?shù)差距就在于有沒(méi)有人提到memo、useCallback、useMemo這三兄弟的配合。父組件里如果傳了內(nèi)聯(lián)函數(shù)給子組件// 父組件每次渲染handleClick都是新函數(shù)React.memo完全失效 Child onClick{() handleClick(id)} /要想讓React.memo生效必須搭配useCallback和useMemo把引用穩(wěn)定住。這是組件通信和渲染優(yōu)化最典型的交匯點(diǎn)也是我在實(shí)際項(xiàng)目中反復(fù)用到的知識(shí)。面試答出這一層遠(yuǎn)比背十個(gè)API名字有說(shuō)服力。6. 常見問(wèn)題與排查技巧實(shí)錄那些年我們踩過(guò)的組件通信坑章節(jié)最后我想聊聊實(shí)操中的問(wèn)題和排查方法。這個(gè)部分每一條都是我在真實(shí)項(xiàng)目和團(tuán)隊(duì)協(xié)作中踩出來(lái)的經(jīng)驗(yàn)。6.1 子組件沒(méi)有更新引用不變才是元兇典型表現(xiàn)為父組件的數(shù)組變了子組件卻不重新渲染。排查路徑第一步永遠(yuǎn)是看“引用變沒(méi)變”。直接push然后setState引用沒(méi)變React淺比較覺(jué)得“沒(méi)有更新”自然不渲染。解決方案前面已經(jīng)提過(guò)用展開運(yùn)算符或者filter/map等不可變操作生成新引用。6.2 React Native白屏問(wèn)題與通信隱患的關(guān)聯(lián)熱詞里有“react native啟動(dòng)白屏”這個(gè)我遇到過(guò)好多次。白屏的原因有很多其中一種很隱蔽的情況是首屏組件在useEffect里等待某個(gè)全局狀態(tài)從“初始值”變成“已加載值”但狀態(tài)更新的回調(diào)在某個(gè)異步流程里沒(méi)被正確觸發(fā)導(dǎo)致UI一直沒(méi)有渲染出來(lái)。這種問(wèn)題本質(zhì)上是組件與狀態(tài)源之間的通信斷鏈了。排查方法是用Redux DevTools或Zustand的日志中間件看看異步流程有沒(méi)有真正dispatch出來(lái)即可快速定位是網(wǎng)絡(luò)問(wèn)題還是狀態(tài)寫入問(wèn)題。6.3 跨組件更新的狀態(tài)無(wú)法追蹤怎么辦如果代碼里使用了大量的Context且Provider的層級(jí)很深你可能會(huì)發(fā)現(xiàn)某次狀態(tài)變更后受影響組件莫名其妙重渲染了。我的排查習(xí)慣是先把Context Provider的value用useMemo包起來(lái)縮小變更范圍再一步步隔離出是哪個(gè)字段的變化引發(fā)的。如果還是查不出來(lái)就借助why-did-you-render這類庫(kù)它能在控制臺(tái)明確打出“哪個(gè)組件因?yàn)槭裁磒rops變化而重渲染”效率拉滿。6.4 我的獨(dú)門調(diào)試技巧最后分享一個(gè)我的調(diào)試心法凡是用props和callback通信的出問(wèn)題直接在React DevTools里看組件樹展開每個(gè)組件的props一眼就能看出數(shù)據(jù)在哪個(gè)環(huán)節(jié)斷了。凡是跨層級(jí)通信的第一時(shí)間打開狀態(tài)管理工具/Context狀態(tài)面板而不是到處打console.log。這兩種方法的本質(zhì)都是“順著數(shù)據(jù)流找斷點(diǎn)”只是工具不同。用熟了以后排查通信類bug的速度至少能快一倍。這篇文章從基礎(chǔ)通信講到了架構(gòu)設(shè)計(jì)從面試題講到了線上排坑。組件通信說(shuō)到底是React世界里最基礎(chǔ)的“數(shù)據(jù)流動(dòng)規(guī)則”但能把它用規(guī)整、用清晰背后體現(xiàn)的是一個(gè)前端工程師對(duì)狀態(tài)邊界的理解力和對(duì)架構(gòu)的判斷力。希望這篇總結(jié)能幫你少走一些彎路。