本文基于一個(gè)真實(shí)踩坑記錄展開帶你徹底理解“為什么明明包了 memo子組件還是跟著父組件亂渲染”。一個(gè)典型的性能浪費(fèi)現(xiàn)場先看你提供的代碼它非常直觀地暴露了問題import { useState, memo } from react; function RegularChild({ name }) { console.log(渲染了RegularChild組件); return h1{name}/h1; } const MemoChild memo(({ name }) { console.log(MemoChild 組件渲染了); return h1Hello, {name}/h1; }); function App() { const [count, setCount] useState(0); const [name, setName] useState(少林隊(duì)); return ( button onClick{() setCount(count 1)}點(diǎn)擊計(jì)數(shù){count}/button button onClick{() setName(峨眉隊(duì))}改變名字/button RegularChild name{name} / MemoChild name{name} / / ); }運(yùn)行一下你會(huì)發(fā)現(xiàn)點(diǎn)擊“點(diǎn)擊計(jì)數(shù)”按鈕count變化了name沒變但是RegularChild和MemoChild都會(huì)重新渲染。只有當(dāng)你再次點(diǎn)擊“改變名字”MemoChild才會(huì)再渲染一次因?yàn)閚ame確實(shí)變了而RegularChild一直傻傻跟著父組件渲染。這里就引出了核心思路React 的渲染是自上而下的“瀑布流”父組件更新默認(rèn)會(huì)帶著所有子組件一起更新。如果你不做任何干預(yù)性能優(yōu)化就無從談起。React.memo組件級(jí)別的淺比較盾牌memo的作用很簡單給你一個(gè)高階組件它會(huì)對傳入的 props 進(jìn)行淺比較如果 props 沒變就跳過渲染直接復(fù)用上一次的結(jié)果。在你的代碼中MemoChild正是憑借memo在count變化而name沒變時(shí)成功避免了無效渲染——這已經(jīng)是一次勝利。但是故事到這里才剛剛開始。很多開發(fā)者會(huì)掉進(jìn)下面這個(gè)陷阱當(dāng) props 里有函數(shù)或?qū)ο髸r(shí)memo 直接“破防”咱們稍微改一下代碼給MemoChild加一個(gè)onClick回調(diào)const MemoChild memo(({ name, onUpdate }) { console.log(MemoChild 渲染了); return ( h1Hello, {name}/h1 button onClick{onUpdate}內(nèi)部改名/button / ); }); function App() { const [count, setCount] useState(0); const [name, setName] useState(少林隊(duì)); // 父組件里定義了一個(gè)回調(diào)函數(shù) const handleUpdate () { setName(內(nèi)部更新的隊(duì)名); }; return ( button onClick{() setCount(count 1)}點(diǎn)擊計(jì)數(shù){count}/button MemoChild name{name} onUpdate{handleUpdate} / / ); }猜一下點(diǎn)擊“點(diǎn)擊計(jì)數(shù)”按鈕MemoChild會(huì)渲染嗎答案是會(huì)盡管name沒變MemoChild依然重渲染了你的memo盾牌好像被什么東西擊穿了。原因很簡單每次App組件渲染里面的handleUpdate都是一個(gè)全新的函數(shù)引用。對于MemoChild來說onUpdate這個(gè) prop 的引用變了淺比較就判定為“props 變化了”于是照常渲染。memo 很忠誠但它只看引用——函數(shù)、對象、數(shù)組只要引用不同就會(huì)觸發(fā)渲染。這才是性能優(yōu)化的暗礁區(qū)。為什么函數(shù)每次都是“全新的引用”你可能會(huì)有疑問明明函數(shù)內(nèi)容一模一樣為什么每次都會(huì)被當(dāng)成不同的東西這要從 React 函數(shù)組件的本質(zhì)說起。函數(shù)組件就是一個(gè)普通的 JavaScript 函數(shù)每次狀態(tài)更新React 都會(huì)重新調(diào)用這個(gè)函數(shù)生成一份全新的“快照”。你寫的handleUpdate是在函數(shù)體內(nèi)部用const聲明的const handleUpdate () { setName(內(nèi)部更新的隊(duì)名); };這行代碼每執(zhí)行一次就會(huì)在內(nèi)存里新創(chuàng)建一個(gè)函數(shù)對象并給handleUpdate分配一個(gè)新的地址。即便兩個(gè)函數(shù)的內(nèi)容完全一樣它們在內(nèi)存中的位置也不同。就像一個(gè)高級(jí)私房菜館你每次都拿一張臨時(shí)手寫的點(diǎn)菜單老板看的是紙本身不是上面的內(nèi)容——紙不一樣就按新單子處理。對于memo來說它比較 props 時(shí)用的是淺比較基本類型比“值”引用類型比“地址”。onUpdate是一個(gè)函數(shù)屬于引用類型所以只要地址變了memo就會(huì)認(rèn)為 prop 更新了于是老老實(shí)實(shí)渲染子組件。你可以直接在代碼里加上一行驗(yàn)證console.log(handleUpdate 引用:, handleUpdate);每點(diǎn)一次按鈕控制臺(tái)顯示的“地址標(biāo)識(shí)”都會(huì)發(fā)生變化。useCallback給函數(shù)一個(gè)“固定住”的引用要解決這個(gè)問題我們就需要讓handleUpdate在多次渲染之間保持同一個(gè)地址除非它真正依賴的某個(gè)值變化了。useCallback就是干這個(gè)的const handleUpdate useCallback(() { setName(內(nèi)部更新的隊(duì)名); }, []);useCallback會(huì)在依賴項(xiàng)這里是空數(shù)組[]不變的情況下直接返回上一次緩存的函數(shù)引用。現(xiàn)在無論你點(diǎn)擊“點(diǎn)擊計(jì)數(shù)”多少次handleUpdate指向的都是同一塊內(nèi)存地址memo淺比較通過子組件也就不會(huì)被帶著跑了。一句話總結(jié)當(dāng)你需要把函數(shù)傳給用memo包裹的子組件時(shí)請用useCallback包裹它否則函數(shù)引用的變化會(huì)讓memo形同虛設(shè)。每次渲染都產(chǎn)生新函數(shù)舊地址去哪了會(huì)不會(huì)內(nèi)存泄漏你可能會(huì)擔(dān)心既然每次渲染都要新建函數(shù)那舊函數(shù)不會(huì)被垃圾清理掉嗎會(huì)不會(huì)內(nèi)存越用越多放心舊函數(shù)會(huì)被 JavaScript 的垃圾回收機(jī)制自動(dòng)清理。只要上一輪渲染產(chǎn)生的handleUpdate沒有被其他地方“抓住”比如傳入全局變量、未清理的定時(shí)器或者閉包泄漏它就變成了“不可達(dá)對象”垃圾回收器會(huì)在合適的時(shí)機(jī)回收它占用的內(nèi)存。useCallback的主要目的并不是節(jié)省內(nèi)存事實(shí)上它反而需要多占用一點(diǎn)點(diǎn)緩存空間而是保持引用穩(wěn)定從而避開memo的無效渲染。這點(diǎn)開銷在避免昂貴渲染的收益面前完全值得。React 不會(huì)讓舊函數(shù)堆積成山。它只是在每次渲染時(shí)短暫存在隨后被清掃你真正要關(guān)心的是“引用變化”帶來的重渲染而不是內(nèi)存泄漏。當(dāng)然如果你在useEffect里錯(cuò)誤地添加了未清理的監(jiān)聽器且監(jiān)聽了某個(gè)內(nèi)聯(lián)函數(shù)那確實(shí)有可能造成內(nèi)存泄漏但那是另一個(gè)需要避免的坑了和這里的場景無關(guān)。useMemo不只是緩存函數(shù)引用還能緩存任何值useMemo和useCallback原理相似但適用范圍更廣useCallback緩存函數(shù)本身useMemo緩存函數(shù)執(zhí)行的結(jié)果可以是任意值最常見的一個(gè)場景昂貴的計(jì)算 子組件傳遞。const MemoList memo(({ data }) { console.log(MemoList 渲染了); return div{data.join(,)}/div; }); function App() { const [count, setCount] useState(0); const [items] useState([1, 2, 3, 4, 5]); // 假設(shè)這是一個(gè)復(fù)雜過濾/排序邏輯 const processedData items.filter(item item 2).sort((a, b) b - a); return ( button onClick{() setCount(count 1)}計(jì)數(shù){count}/button MemoList data{processedData} / / ); }點(diǎn)擊按鈕MemoList依然重渲染。因?yàn)閜rocessedData在每次渲染時(shí)都是一個(gè)新數(shù)組引用。哪怕內(nèi)容完全一樣淺比較也會(huì)認(rèn)為它變了。這時(shí)候就該useMemo出場了const processedData useMemo(() { return items.filter(item item 2).sort((a, b) b - a); }, [items]); // items 不變結(jié)果引用就不變現(xiàn)在processedData的引用在items不變時(shí)會(huì)保持穩(wěn)定memo(子組件)也就能正常工作。另附一個(gè)經(jīng)典踩坑有很多人直接用useMemo緩存 JSX比如const child useMemo(() MemoChild name{name} /, [name]); return {child}/;這確實(shí)能避免子組件不必要的渲染但代碼可讀性差且破壞了 React 的 diff 邏輯。原則上更推薦用memo包裹子組件 useCallback/useMemo穩(wěn)定 props而不是用useMemo直接把 JSX 緩存掉。它們之間的配合關(guān)系memo是子組件側(cè)的防御機(jī)制props 不變我就不渲染。useCallback和useMemo是父組件側(cè)的穩(wěn)定工具確保傳給子組件的 props函數(shù)、對象、數(shù)組引用不變。三者配合才能真正做到“不相關(guān)狀態(tài)更新時(shí)子組件紋絲不動(dòng)”。再補(bǔ)一句很多人忽視的事實(shí)useCallback和useMemo本身也有開銷。如果你傳給的只是一個(gè)普通div或者根本沒有被memo包裹的子組件那反而是一種浪費(fèi)。它們只在結(jié)合memo使用或作為其他 Hook 的依賴項(xiàng)時(shí)才真正發(fā)揮威力。一個(gè)“可落地”的優(yōu)化步驟 checklist如果你在項(xiàng)目中遇到某個(gè)頁面渲染卡頓或者子組件無緣無故跟著父親亂抖可以按下面的步驟排查確認(rèn)渲染范圍用console.log或者 React DevTools 的 Highlight 功能看哪些組件在不必渲染時(shí)也渲染了。對純展示、且依賴穩(wěn)定的子組件包上memo注意只對 props 基本穩(wěn)定的組件做別一股腦全包。檢查傳給子組件的引用類型 props如果有函數(shù)、對象、數(shù)組看看它們在父組件中是否每次渲染都重新創(chuàng)建。用useCallback穩(wěn)定函數(shù)用useMemo穩(wěn)定對象/數(shù)組/計(jì)算結(jié)果依賴項(xiàng)要寫準(zhǔn)確避免閉包陷阱比如忘了依賴某個(gè) state。確認(rèn)優(yōu)化有效再用 console 或 DevTools profiler 驗(yàn)證一下子組件是否真的跳過了渲染。最后說一個(gè)容易被忽略的思維升級(jí)很多教程會(huì)說useCallback和useMemo是用來“緩存函數(shù)”和“緩存計(jì)算結(jié)果”的但它們真正的定位是引用穩(wěn)定性。你的目標(biāo)是讓那些被memo保護(hù)的子組件收到的 props 引用不要無意義地變化從而避免重渲染。寫性能優(yōu)化的代碼本質(zhì)上是在管理“變化” —— 你告訴 React 什么真正變化了什么只是看起來變化了。memo 是盾useCallback/useMemo 是矛你要把矛頭準(zhǔn)確扎向“假變化”。