先還原一個(gè)我再熟悉不過(guò)的場(chǎng)景項(xiàng)目里有個(gè)定時(shí)刷新列表的功能setInterval每 5 秒拉一次接口useEffect里把篩選條件當(dāng)成依賴(lài)。邏輯理得很順一上線就翻車(chē)——頁(yè)面上點(diǎn)的篩選條件總是慢一拍日志里看到的參數(shù)永遠(yuǎn)是上一次的值。排查到最后發(fā)現(xiàn)問(wèn)題不在接口也不在緩存而是 React 里一個(gè)特別隱蔽、又幾乎人人踩過(guò)的坑閉包陷阱。網(wǎng)上聊這個(gè)主題的帖子不少但大多數(shù)只給一個(gè)結(jié)論——在依賴(lài)數(shù)組里加上那個(gè)變量就好了很少有人講清楚為什么每次渲染會(huì)形成獨(dú)立的閉包、為什么有的修法越修越壞。這篇文章不打算講太多理論教條我會(huì)從原理、實(shí)戰(zhàn)、排查工具、面試視角四個(gè)層面完整拆一遍爭(zhēng)取你看完既能看懂根因也能真正做到舉一反三。1. 先搞懂閉包陷阱到底是什么1.1 一個(gè) 5 行代碼就能復(fù)現(xiàn)的經(jīng)典 bug先看一個(gè)最簡(jiǎn)單的例子這幾乎是所有閉包陷阱的最小復(fù)現(xiàn)模型function Counter() { const [count, setCount] useState(0); useEffect(() { setInterval(() { console.log(count); // 永遠(yuǎn)輸出 0 }, 1000); }, []); return ( button onClick{() setCount(count 1)} 點(diǎn)了 {count} 次 /button ); }點(diǎn)擊按鈕讓count增加界面上的數(shù)字確實(shí)變了但控制臺(tái)里定時(shí)器打印的值永遠(yuǎn)是初始的0。如果你沒(méi)搞懂原因可能會(huì)往setInterval本身去查——定時(shí)器沒(méi)清回調(diào)沒(méi)重新綁定排查一圈發(fā)現(xiàn)都不是。問(wèn)題的根源在useEffect的依賴(lài)數(shù)組[]。這個(gè)空數(shù)組意味著只在掛載時(shí)執(zhí)行一次定時(shí)器的回調(diào)在掛載那次渲染中被創(chuàng)建而那次渲染里的count是初始值0。這個(gè)回調(diào)閉包捕獲了0之后每次點(diǎn)擊產(chǎn)生的新count它根本感知不到。1.2 為什么每次渲染都在拍照閉包與渲染快照的關(guān)系要理解這個(gè)陷阱得先建立一個(gè)關(guān)鍵認(rèn)知React 函數(shù)組件每次渲染都是一次獨(dú)立的快照。想象組件是一個(gè)函數(shù)每次渲染都在調(diào)用這個(gè)函數(shù)。useState返回的count只是這次調(diào)用中的一個(gè)局部變量一個(gè)數(shù)字快照。當(dāng)你在這次渲染里創(chuàng)建了一個(gè)函數(shù)比如setInterval的回調(diào)這個(gè)函數(shù)就會(huì)捕獲本次渲染的count。等下一次渲染時(shí)組件函數(shù)重新執(zhí)行新的count出現(xiàn)了但定時(shí)器回調(diào)還是上一次渲染留下的老函數(shù)——它閉包里的count永遠(yuǎn)停留在創(chuàng)建那一刻。這和 JavaScript 閉包的機(jī)制完全一致。一個(gè)函數(shù)內(nèi)部引用外部變量外部變量是按值捕獲對(duì)原始類(lèi)型而言還是按引用捕獲對(duì)對(duì)象而言決定了它讀取到的是哪份數(shù)據(jù)。React 的state是不可變數(shù)據(jù)每次更新都會(huì)產(chǎn)生新值舊閉包握著的始終是舊值。提示很多人說(shuō)閉包陷阱是 React 的 bug這話不對(duì)。它是 React 聲明式模型每次渲染重新執(zhí)行組件函數(shù)和閉包特性捕獲創(chuàng)建時(shí)刻的變量組合起來(lái)的必然結(jié)果。理解這一點(diǎn)比死記多少條修復(fù)規(guī)則都重要。1.3 陷阱不是 bug是聲明式模型的必然代價(jià)React 選擇每次渲染都是全新快照這個(gè)模型換來(lái)的是 UI 的可預(yù)測(cè)性和調(diào)試友好。你可以放心地認(rèn)為這次渲染里看到的props、state就是這次 UI 所對(duì)應(yīng)的那套數(shù)據(jù)。代價(jià)就是任何跨越渲染存活的東西定時(shí)器、事件監(jiān)聽(tīng)、異步回調(diào)都可能碰到舊閉包問(wèn)題。這和類(lèi)組件時(shí)代的this.state有本質(zhì)區(qū)別。類(lèi)組件里this是同一個(gè)實(shí)例this.state永遠(yuǎn)指向最新值所以很少有人抱怨閉包問(wèn)題。Hooks 全面普及后函數(shù)組件配合閉包把這個(gè)問(wèn)題徹底暴露了出來(lái)。再加上 Hooks 依賴(lài)數(shù)組的設(shè)計(jì)漏寫(xiě)依賴(lài)幾乎成了新手到資深都會(huì)踩的坑。2. 四個(gè)高頻翻車(chē)現(xiàn)場(chǎng)與現(xiàn)場(chǎng)拆解2.1 useEffect 空依賴(lài)定時(shí)器永遠(yuǎn)讀不到最新值開(kāi)頭那個(gè)計(jì)數(shù)器就是典型。實(shí)際業(yè)務(wù)里最常見(jiàn)的是輪詢(xún)接口 篩選條件的組合。比如這樣function ListPage({ keyword }) { const [list, setList] useState([]); useEffect(() { const timer setInterval(async () { const res await fetch(/api/list?keyword${keyword}); const data await res.json(); setList(data); }, 5000); return () clearInterval(timer); }, []); // keyword 在閉包里被焊死了 // ... }keyword是父組件傳下來(lái)的 props用戶(hù)在搜索框里輸入新詞后列表還是要拿舊詞去查詢(xún)。組件重新渲染了keyword變了但定時(shí)器回調(diào)里捕獲的仍是第一次渲染時(shí)的舊keyword。這個(gè)案例里有兩個(gè)修法方向把keyword加進(jìn)依賴(lài)數(shù)組[keyword]每次關(guān)鍵詞變化就重建定時(shí)器。缺點(diǎn)很明顯——重建定時(shí)器意味著計(jì)時(shí)中斷如果用戶(hù)頻繁改篩選條件定時(shí)器可能永遠(yuǎn)等不到 5 秒。用useRef持有keyword的最新值定時(shí)器回調(diào)里通過(guò)ref.current讀取。這樣定時(shí)器只建一次讀取的值永遠(yuǎn)是最新的。推薦后者因?yàn)檩喸?xún)場(chǎng)景下定時(shí)器不中斷通常比反復(fù)重建體驗(yàn)更好而且性能開(kāi)銷(xiāo)更小。const keywordRef useRef(keyword); useEffect(() { keywordRef.current keyword; }, [keyword]); useEffect(() { const timer setInterval(async () { const res await fetch(/api/list?keyword${keywordRef.current}); const data await res.json(); setList(data); }, 5000); return () clearInterval(timer); }, []);這里有個(gè)細(xì)節(jié)為什么需要額外的useEffect去更新ref.current你在渲染期直接寫(xiě)keywordRef.current keyword行不行嚴(yán)格模式下渲染期修改 ref 是一種反模式React 官方不推薦。因?yàn)殇秩究赡鼙?React 重復(fù)調(diào)用比如StrictMode下會(huì)雙調(diào)用渲染寫(xiě) ref 會(huì)產(chǎn)生難以追蹤的副作用。放在useEffect里是渲染完成后同步時(shí)序上不會(huì)破壞任何一次渲染的快照性。2.2 useCallback 保存舊引用子組件瘋狂重渲染/拿到舊回調(diào)useCallback本意是穩(wěn)定函數(shù)引用減少子組件不必要渲染但它同時(shí)也是閉包陷阱的重災(zāi)區(qū)。看這個(gè)例子function Parent() { const [id, setId] useState(1); const fetchDetail useCallback(() { // 這里使用的 id 是創(chuàng)建 useCallback 時(shí)的 id fetch(/api/detail/${id}); }, []); // 空依賴(lài)id 被鎖死 return Child onFetch{fetchDetail} /; }子組件Child每次拿到的都是同一個(gè)fetchDetail引用所以React.memo的效果達(dá)到了——不重渲染。但當(dāng)id變化后這個(gè)回調(diào)函數(shù)體里的id還是舊值子組件點(diǎn)擊觸發(fā)時(shí)請(qǐng)求的是上一次的id。這種 bug 非常隱蔽因?yàn)樽咏M件不重渲染這件事本身會(huì)被當(dāng)成正確信號(hào)。你排查性能問(wèn)題時(shí)會(huì)很滿意直到發(fā)現(xiàn)數(shù)據(jù)不對(duì)。正確做法是給useCallback補(bǔ)上依賴(lài)const fetchDetail useCallback(() { fetch(/api/detail/${id}); }, [id]);代價(jià)是id一變fetchDetail引用也會(huì)變React.memo被打破子組件要重渲染。這是正確的取舍——引用穩(wěn)定性必須讓位于數(shù)據(jù)正確性。如果子組件重渲染成本很高優(yōu)先考慮把變化的部分拆出去比如把id作為參數(shù)傳給回調(diào)而不是捕獲進(jìn)閉包c(diǎn)onst fetchDetail useCallback((targetId) { fetch(/api/detail/${targetId}); }, []);這樣回調(diào)不看任何外部狀態(tài)引用永遠(yuǎn)穩(wěn)定調(diào)用時(shí)傳參傳入最新的id。這是我在項(xiàng)目里最常用的一招。2.3 異步請(qǐng)求的回調(diào)用戶(hù)操作后狀態(tài)悄悄回退再來(lái)看一類(lèi)不那么直觀的翻車(chē)現(xiàn)場(chǎng)。假設(shè)有這樣一個(gè)場(chǎng)景用戶(hù)點(diǎn)擊保存按鈕后組件發(fā)起一個(gè)請(qǐng)求等請(qǐng)求回來(lái)再setState更新頁(yè)面狀態(tài)。請(qǐng)求期間用戶(hù)又做了一些操作改變了一些狀態(tài)。如果請(qǐng)求回調(diào)是舊的閉包它setState時(shí)用的可能是過(guò)期的數(shù)據(jù)。function Editor() { const [content, setContent] useState(); const [saving, setSaving] useState(false); const save () { setSaving(true); api.save(content).then(() { setSaving(false); // 如果 content 在請(qǐng)求期間被修改 // 這里的 success 提示是基于舊 content 的 }); }; // ... }這類(lèi)問(wèn)題不總是表現(xiàn)為崩潰級(jí) bug更多時(shí)候是詭異的狀態(tài)回退用戶(hù)以為已經(jīng)改了新內(nèi)容界面上卻顯示舊內(nèi)容保存成功。這類(lèi)場(chǎng)景的排查難點(diǎn)在于它沒(méi)有明顯的時(shí)序錯(cuò)誤看起來(lái)只是偶爾不對(duì)。真正可靠的解決思路是回調(diào)內(nèi)部不依賴(lài)任何渲染期快照而是讀取最新的 ref 值或者干脆把請(qǐng)求參數(shù)傳參傳進(jìn)去。const contentRef useRef(content); useEffect(() { contentRef.current content; }, [content]); const save () { const snapshot contentRef.current; setSaving(true); api.save(snapshot).then(() { setSaving(false); }); };contentRef提供的是一個(gè)跨渲染的可變通道任何時(shí)候讀contentRef.current都能拿到最新的content。請(qǐng)求回調(diào)從這個(gè)通道讀數(shù)就不會(huì)被閉包鎖死。2.4 事件監(jiān)聽(tīng)器addEventListener 與閉包的雙重陷阱Hooks 時(shí)代還有一個(gè)非常經(jīng)典的場(chǎng)景——手動(dòng)給window或document綁定事件。這種監(jiān)聽(tīng)器只在掛載時(shí)綁定一次回調(diào)里捕獲的永遠(yuǎn)是首次渲染的值。function useKeyPress() { const [key, setKey] useState(); useEffect(() { const handler (e) { setKey(e.key); console.log(current key:, key); // 永遠(yuǎn)打印初始值 }; window.addEventListener(keydown, handler); return () window.removeEventListener(keydown, handler); }, []); // ... }修復(fù)同樣靠useRef。凡是只綁定一次、但回調(diào)里要讀最新?tīng)顟B(tài)的監(jiān)聽(tīng)器一律走 ref 通道const keyRef useRef(key); keyRef.current key; // 渲染期直接寫(xiě)見(jiàn)下方說(shuō)明 useEffect(() { const handler (e) { setKey(e.key); console.log(current key:, keyRef.current); }; window.addEventListener(keydown, handler); return () window.removeEventListener(keydown, handler); }, []);不過(guò)渲染期直接寫(xiě)keyRef.current key這個(gè)問(wèn)題我在 2.1 里提過(guò)一句React 官方不推薦在渲染期寫(xiě) ref因?yàn)樵诓l(fā)渲染下渲染可能被中斷中斷后恢復(fù)可能導(dǎo)致 ref 與 state 不一致。穩(wěn)妥的寫(xiě)法是在useEffect里同步useEffect(() { keyRef.current key; }, [key]);雖然多寫(xiě)一個(gè) effect 有點(diǎn)啰嗦但換來(lái)的是渲染期不做副作用的確定性。對(duì)關(guān)鍵業(yè)務(wù)代碼這個(gè)取舍值得。3. 修復(fù)方案實(shí)測(cè)哪些能用、哪些是坑3.1 useRef 攜帶最新值最通用的方案及其副作用useRef是閉包陷阱的第一選擇卻也不是銀彈。使用時(shí)有幾個(gè)副作用你得知道。第一個(gè)是渲染期寫(xiě) ref 的節(jié)律問(wèn)題。上面已經(jīng)強(qiáng)調(diào)過(guò)渲染函數(shù)里ref.current xxx是一種反模式。你在StrictMode下可能被調(diào)用兩次ref 被寫(xiě)兩次在并發(fā)渲染下渲染可能被打斷ref 寫(xiě)入的時(shí)間點(diǎn)變得不可控。把 ref 同步放在useEffect里雖然多一幀晚一點(diǎn)但是可靠的。第二個(gè)是ref 不是響應(yīng)式的。修改ref.current不會(huì)觸發(fā)組件重新渲染。如果你試圖用 ref 來(lái)鏡像狀態(tài)然后還期望 UI 跟著變你會(huì)在界面上看到舊數(shù)據(jù)半天不刷新。第三個(gè)是濫用 ref 會(huì)讓代碼變得難懂。一個(gè)組件里塞五六個(gè) ref每個(gè)都在 effect 里同步邏輯一多根本分不清誰(shuí)是誰(shuí)的鏡像。我的經(jīng)驗(yàn)是能少用就少用能用函數(shù)式更新解決就不用 ref畢竟維護(hù)成本是實(shí)打?qū)嵉摹?.2 函數(shù)式更新setState(prev ...) 的正確打開(kāi)方式如果你需要的只是基于最新 state 更新 state那根本不用 refsetState的函數(shù)式更新就夠了。setCount(prev prev 1); setList(prev [...prev, newItem]);prev是 React 在更新時(shí)傳入的最新?tīng)顟B(tài)不依賴(lài)閉包捕獲。這個(gè)用法在定時(shí)器、事件回調(diào)里都安全。尤其多個(gè)setState連在一起時(shí)函數(shù)式更新能避免批量更新時(shí)的舊值覆蓋問(wèn)題。還有一個(gè)進(jìn)階技巧函數(shù)式更新可以完美解決定時(shí)器里反復(fù)累加的場(chǎng)景。useEffect(() { const timer setInterval(() { setCount(prev prev 1); }, 1000); return () clearInterval(timer); }, []);這段代碼無(wú)論組件重新渲染多少次定時(shí)器回調(diào)都拿不到count但setCount的函數(shù)式寫(xiě)法讓它永遠(yuǎn)基于最新值計(jì)算。既不需要重建定時(shí)器也不需要 ref邏輯最干凈。不過(guò)函數(shù)式更新有它的邊界它只覆蓋基于 state 計(jì)算 state的場(chǎng)景。如果你需要讀取狀態(tài)去調(diào)用接口、埋點(diǎn)、或者做條件判斷函數(shù)式更新就無(wú)能為力了這時(shí)候還是得靠 ref。3.3 正確配置依賴(lài)useCallback/useMemo/useEffect 的依賴(lài)到底怎么填依賴(lài)數(shù)組是 Hooks 閉包問(wèn)題的官方解藥但很多人只知要加依賴(lài)不知加哪些、為什么加。依賴(lài)數(shù)組的規(guī)則其實(shí)很樸素你的回調(diào)函數(shù)中使用的外部值都要出現(xiàn)在依賴(lài)數(shù)組里。eslint-plugin-react-hooks的exhaustive-deps規(guī)則就是幫你檢查這件事的。一個(gè)典型的誤區(qū)是我把依賴(lài)都加了但 effect 總是頻繁執(zhí)行。比如useEffect(() { // 只要 parent 每次渲染創(chuàng)建一個(gè)新的 object // 這個(gè) effect 就每次都會(huì)跑 fetch(/api/data?params${JSON.stringify(params)}); }, [params]);問(wèn)題不出在 加了依賴(lài)而在于params對(duì)象是一個(gè)不穩(wěn)定引用——每次渲染都新建一個(gè)。解法有兩個(gè)方向組件內(nèi)部可以先useMemo穩(wěn)定引用只讓 effect 依賴(lài)useMemo的結(jié)果。如果不需要響應(yīng)變化用 ref 通道繞開(kāi)效果或者把必要的值傳參給回調(diào)。依賴(lài)數(shù)組的核心心法依賴(lài)數(shù)組是效果何時(shí)重新執(zhí)行的開(kāi)關(guān)不是回調(diào)內(nèi)捕獲值是否最新的保證。只要回調(diào)里引用了外部變量卻在依賴(lài)?yán)锫┑羲黚ug 必然出現(xiàn)。你只能選擇把它加進(jìn)依賴(lài)或用 ref 繞開(kāi)快照沒(méi)有第三條路。3.4 useReducer 兜底復(fù)雜狀態(tài)機(jī)的最佳選擇當(dāng)狀態(tài)更新邏輯變復(fù)雜多個(gè)useState互相依賴(lài)、還夾帶著異步流程時(shí)useState加 ref 的組合可能會(huì)讓代碼越來(lái)越亂。這時(shí)候useReducer是一個(gè)非常好的兜底方案。const initialState { data: null, loading: false, error: null }; function reducer(state, action) { switch (action.type) { case FETCH_START: return { ...state, loading: true }; case FETCH_SUCCESS: return { ...state, loading: false, data: action.payload }; case FETCH_ERROR: return { ...state, loading: false, error: action.payload }; default: return state; } } function DataView({ url }) { const [state, dispatch] useReducer(reducer, initialState); const fetchData useCallback(() { dispatch({ type: FETCH_START }); fetch(url) .then(res res.json()) .then(payload dispatch({ type: FETCH_SUCCESS, payload })) .catch(error dispatch({ type: FETCH_ERROR, error })); }, [url]); // ... }useReducer的dispatch在渲染之間是穩(wěn)定的React 保證所以你可以放心在閉包里使用它。狀態(tài)轉(zhuǎn)移被封裝成純函數(shù)根本不存在閉包里狀態(tài)過(guò)期的問(wèn)題——因?yàn)闋顟B(tài)不在閉包里而在 reducer 的參數(shù)里。這也是我處理復(fù)雜業(yè)務(wù)狀態(tài)時(shí)偏愛(ài)的模式用useReducer替代多個(gè)useState 多個(gè) ref的堆砌。3.5 高階進(jìn)階為什么 startTransition 下更危險(xiǎn)聊到 React 18 引入的并發(fā)特性和startTransition閉包陷阱會(huì)有一個(gè)更隱蔽的表現(xiàn)形式——過(guò)渡更新被中斷后重新執(zhí)行閉包捕獲的值可能來(lái)自過(guò)期的那次渲染。startTransition允許 React 暫緩低優(yōu)先級(jí)更新。假設(shè)你在一個(gè)transition更新中讀取 state 并生成派生數(shù)據(jù)渲染被高優(yōu)先級(jí)更新打斷后React 會(huì)回到之前的狀態(tài)快照重新渲染。如果代碼里混著閉包捕獲舊值這次恢復(fù)渲染可能把舊值帶回來(lái)產(chǎn)生界面跳變。這個(gè)場(chǎng)景對(duì)大多數(shù)項(xiàng)目來(lái)說(shuō)確實(shí)不那么高頻但理解它有助于建立更完整的圖景。建議在并發(fā)特性下凡是渲染期間派生數(shù)據(jù)的邏輯優(yōu)先用純函數(shù)計(jì)算避免在渲染函數(shù)內(nèi)部讀寫(xiě) ref。如果拿不準(zhǔn)就沿用并發(fā)特性之前的習(xí)慣把耗時(shí)、異步的事放到useEffect或事件回調(diào)里別用渲染函數(shù)做狀態(tài)協(xié)調(diào)。4. 排查工具箱從抓狂到五分鐘定位4.1 第一板斧渲染函數(shù)里打 console.log閉包問(wèn)題最迷惑人的地方在于界面上看起來(lái)值是對(duì)的渲染用的 state 是新值但回調(diào)里拿到的值是舊的閉包捕獲的是舊快照。所以排查的第一步永遠(yuǎn)是區(qū)分渲染值和回調(diào)值。在組件函數(shù)體里打一個(gè)console.log(render:, count)在回調(diào)里也打一個(gè)console.log(callback:, count)。如果渲染值每次都變回調(diào)值始終不變基本可以斷定是閉包陷阱。function Demo() { const [count, setCount] useState(0); console.log(render:, count); // 每次渲染都執(zhí)行 useEffect(() { const timer setInterval(() { console.log(callback:, count); // 固定不變 }, 1000); return () clearInterval(timer); }, []); return button onClick{() setCount(c c 1)}1/button; }看到兩個(gè)日志的差異接下來(lái)直接檢查那個(gè)閉包所在的函數(shù)是在哪次渲染里創(chuàng)建的——回調(diào)創(chuàng)建于useEffect的依賴(lài)數(shù)組為[]的首次渲染自然讀到的就是首次渲染的count。4.2 第二板斧ref 打印最新值對(duì)照理解原理后可以用 ref 做一個(gè)對(duì)照實(shí)驗(yàn)快速驗(yàn)證修復(fù)方向const countRef useRef(count); useEffect(() { countRef.current count; }, [count]);結(jié)果callback: countRef.current的打點(diǎn)開(kāi)始跟隨最新值。這個(gè)對(duì)照實(shí)驗(yàn)非常重要它不是讓你修 bug而是幫你確認(rèn)讀到的值來(lái)自哪個(gè)獲取通道。閉包讀快照ref 讀實(shí)況。用兩個(gè)通道的值做對(duì)比問(wèn)題定位通常在一分鐘內(nèi)完成。4.3 第三板斧eslint-plugin-react-hooks 配置與 useCallback 的意義閉包問(wèn)題其實(shí)有相當(dāng)一部分靠靜態(tài)檢查就能攔下來(lái)。eslint-plugin-react-hooks里的exhaustive-deps規(guī)則是 React 官方推薦的必裝配置。// eslint 配置 { rules: { react-hooks/exhaustive-deps: warn } }它能把你在 effect 里用了count但依賴(lài)數(shù)組是[]的情況直接以警告形式標(biāo)出來(lái)。我建議把它設(shè)置成error因?yàn)橐坏┧卸ㄒ蕾?lài)缺失幾乎就是真實(shí) bug 信號(hào)。團(tuán)隊(duì)協(xié)作時(shí)這個(gè)規(guī)則配合 code review能擋住大部分新手誤操作。注意依賴(lài)數(shù)組里寫(xiě)[]不一定是錯(cuò)的。有些 effect 就是只在掛載時(shí)訂閱并且回調(diào)內(nèi)部只使用 ref 通道讀取動(dòng)態(tài)值。這種情況下 eslint 可能會(huì)誤報(bào)。你可以在數(shù)組里寫(xiě)上 ref 本身比如[countRef]它不會(huì)變化卻能讓 lint 認(rèn)為依賴(lài)已被聲明同時(shí)也不影響執(zhí)行時(shí)機(jī)。如果你覺(jué)得這個(gè)寫(xiě)法不夠優(yōu)雅也可以關(guān)掉對(duì)應(yīng)行的 lint但要確保自己寫(xiě)的時(shí)候能承擔(dān)這個(gè)我確認(rèn)沒(méi)問(wèn)題的責(zé)任。4.4 一個(gè)實(shí)際案例的完整排查過(guò)程我之前維護(hù)過(guò)一個(gè)實(shí)時(shí)消息列表每隔 3 秒要拉一次新消息但用戶(hù)翻頁(yè)后列表自動(dòng)刷新總是跳回第一頁(yè)。初看是翻頁(yè)狀態(tài)被覆蓋排查代碼后才發(fā)現(xiàn)輪詢(xún)回調(diào)是一個(gè)useEffect的空依賴(lài)[]建立的閉包閉包捕獲了currentPage初始為 1每次拉接口用的都是currentPage這個(gè)舊值setList拿到的數(shù)據(jù)是第一頁(yè)頁(yè)面自然跳回第一頁(yè)。當(dāng)時(shí)的修復(fù)思路很簡(jiǎn)單輪詢(xún)和翻頁(yè)是兩套邏輯輪詢(xún)需要持續(xù)讀最新currentPage我用 ref 做通道解決輪詢(xún)定時(shí)器保持不重建。如果你直接把currentPage加進(jìn)依賴(lài)數(shù)組同樣能工作但問(wèn)題在于——每翻頁(yè)一次定時(shí)器就重建如果用戶(hù)連續(xù)翻頁(yè)可能出現(xiàn)定時(shí)器永不觸達(dá)的尷尬。所以 ref 方案更符合業(yè)務(wù)訴求。5. 面試官視角閉包陷阱怎么答才不扣分5.1 考點(diǎn)拆解從現(xiàn)象到原理再到方案的三層結(jié)構(gòu)閉包陷阱是 React 面試的經(jīng)典高頻題。這兩年面試風(fēng)向已經(jīng)從背結(jié)論轉(zhuǎn)向講原理所以答題要有層次。推薦順序是現(xiàn)象 → 原理 → 方案 → 場(chǎng)景四層現(xiàn)象層一句話描述——用useEffect、useCallback、事件監(jiān)聽(tīng)時(shí)回調(diào)內(nèi)部讀到的 props/state 總是舊值。原理層講清楚每次渲染都是獨(dú)立快照函數(shù)組件里所有函數(shù)都捕獲本次渲染的 props/state跨越渲染存活的回調(diào)定時(shí)器、事件、異步請(qǐng)求會(huì)持有舊快照。方案層講出至少兩種解法——函數(shù)式更新setState(prev ...)和useRef跨渲染可變通道順便對(duì)比它們的適用場(chǎng)景狀態(tài)計(jì)算用函數(shù)式更新讀取狀態(tài)做副作用用 ref。場(chǎng)景層舉一個(gè)你真實(shí)遇到過(guò)的例子比如我開(kāi)頭說(shuō)的輪詢(xún)列表把你當(dāng)時(shí)的排查思路、修復(fù)過(guò)程和取舍講出來(lái)。5.2 別踩的雷把解決方案說(shuō)成依賴(lài)數(shù)組包一下很多候選人的回答止步于在依賴(lài)數(shù)組里加上那個(gè)變量這個(gè)回答只能得個(gè)及格分。原因是它只講了怎么做沒(méi)回答為什么這么做和什么情況下這么做不完全管用。舉一個(gè)反例如果問(wèn)題的場(chǎng)景是定時(shí)器必須保持穩(wěn)定不重建同時(shí)要讀最新值這時(shí)單純加依賴(lài)會(huì)適得其反。所以面試官真正想聽(tīng)到的是你理解依賴(lài)數(shù)組的機(jī)制同時(shí)知道它有邊界能針對(duì)不同場(chǎng)景給出更合適的方案。如果你能順帶提到useReducer的dispatch是穩(wěn)定引用、可用于閉包場(chǎng)景以及 React 18 并發(fā)渲染下閉包陷阱更隱蔽面試官會(huì)明顯感覺(jué)到這不是背題而是吃過(guò)虧后的體系化理解。6. 個(gè)人經(jīng)驗(yàn)與踩坑補(bǔ)充React 開(kāi)發(fā)這幾年閉包陷阱幾乎是我在團(tuán)隊(duì)里答疑最高頻的三大問(wèn)題之一。剛開(kāi)始我也很受傷記得有一次為了一個(gè)上傳進(jìn)度條卡死的問(wèn)題查了一下午最后發(fā)現(xiàn)就是上傳回調(diào)閉包捕獲了舊的 progress state——組件更新了回調(diào)里讀到的還是初始值。后來(lái)我慢慢形成了一個(gè)習(xí)慣寫(xiě) useEffect、useCallback、事件監(jiān)聽(tīng)或者任何跨渲染存活的函數(shù)時(shí)先問(wèn)自己三句話——這個(gè)函數(shù)會(huì)在我預(yù)期之外的時(shí)間點(diǎn)被調(diào)用嗎定時(shí)器、異步回調(diào)、事件監(jiān)聽(tīng)都會(huì)函數(shù)體里引用了哪些 props 和 state這些值我希望是最新值還是創(chuàng)建時(shí)刻的值如果是最新值直接考慮函數(shù)式更新或 ref如果是創(chuàng)建時(shí)刻的值也要想清楚此刻快照是不是目標(biāo)值。這個(gè)自檢流程幫我避免了一大批閉包 bug。另外一個(gè)容易被忽略的小技巧用useCallback時(shí)優(yōu)先考慮傳遞參數(shù)而非捕獲變量。當(dāng)一個(gè)回調(diào)不需要從閉包里讀取任何動(dòng)態(tài)值時(shí)它的引用就是天然穩(wěn)定的依賴(lài)數(shù)組可以是空的這既躲開(kāi)了閉包陷阱又天然滿足React.memo的性能優(yōu)化需求。最初你可能不習(xí)慣這種寫(xiě)法但它確實(shí)是我實(shí)踐中體驗(yàn)最好的一種模式。閉包陷阱本身不可怕可怕的是誤打誤撞修好了卻不知道正確性出自哪里。希望這篇分享能幫你建立每次渲染都是快照、跨渲染讀最新值走 ref、狀態(tài)計(jì)算用函數(shù)式更新這三個(gè)核心認(rèn)知。用這套框架去審視代碼很多看似詭異的 bug你一眼就能看穿。