看到“rea”這個(gè)詞我一愣。它的拼寫讓我想起過(guò)去幾年我一直離不開(kāi)的那套前端技術(shù)棧以及我給自己那些React實(shí)戰(zhàn)筆記起的內(nèi)部代號(hào)——某一天整理文檔時(shí)隨手敲下的三個(gè)字母后來(lái)就成了這套筆記的代稱。這三年里我用這套“rea”筆記記錄了大大小小幾十個(gè)項(xiàng)目的踩坑與重構(gòu)過(guò)程從最初的組件堆砌到后來(lái)能夠比較清晰地理解決策鏈路上的每個(gè)環(huán)節(jié)中間經(jīng)歷了很多次推翻重來(lái)。這篇文章是我把自己這些年React實(shí)踐里沉淀下來(lái)的東西做了一次系統(tǒng)的整理圍繞“為什么這么寫”而不是“API怎么用”來(lái)展開(kāi)。它不是什么源碼級(jí)別的底層解析更不是一份面面俱到的官方文檔翻譯而是一個(gè)普通開(kāi)發(fā)者從“能寫組件”到“開(kāi)始理解渲染”的真實(shí)復(fù)盤。適合幾類人看準(zhǔn)備做React技術(shù)重構(gòu)的團(tuán)隊(duì)、剛掌握J(rèn)SX語(yǔ)法但總覺(jué)得差一口氣的初中級(jí)開(kāi)發(fā)者、被組件渲染性能和狀態(tài)管理反復(fù)折磨的人。如果你正卡在這些問(wèn)題的某個(gè)節(jié)點(diǎn)上這篇文章大概率能幫你把思路理順。1. rea的來(lái)龍去脈先說(shuō)清楚React到底解決了什么問(wèn)題1.1 “rea”不是框架是三個(gè)字母背后的邊界感很多人在入門前端的第一天就直接上手React然后很快就能寫出一個(gè)能跑的頁(yè)面。這個(gè)速度給了人一種錯(cuò)覺(jué)React挺簡(jiǎn)單的。但真正深入之后你會(huì)發(fā)現(xiàn)日常開(kāi)發(fā)中大部分Bug和性能問(wèn)題根源都出在對(duì)“React到底是什么”的理解偏差上。React本質(zhì)上是一個(gè)視圖層庫(kù)不是一個(gè)全?？蚣芨皇且粋€(gè)完整的應(yīng)用解決方案。它的核心工作是一個(gè)三元組組件、狀態(tài)、渲染。組件由UI和邏輯構(gòu)成狀態(tài)分為本地狀態(tài)和全局狀態(tài)渲染則是一切問(wèn)題的匯聚點(diǎn)。理解這三者之間的關(guān)系是讀懂后面所有內(nèi)容的前提。我曾經(jīng)在某個(gè)模擬項(xiàng)目里接盤了一個(gè)React老項(xiàng)目里面隨處可見(jiàn)直接在組件外部操作全局變量的寫法。表面上看頁(yè)面還能運(yùn)行但一旦數(shù)據(jù)發(fā)生變更整個(gè)頁(yè)面都不會(huì)響應(yīng)——因?yàn)镽eact根本不知道外部數(shù)據(jù)變了。這種問(wèn)題不是React的Bug而是使用者在用一種“jQuery思維”來(lái)寫React?，F(xiàn)象就是頁(yè)面變成了一個(gè)一次性渲染的靜態(tài)快照失去了響應(yīng)式能力。1.2 從“會(huì)寫組件”到“理解渲染”中間隔著一道海會(huì)寫JSX、會(huì)用useState、能把組件拆出來(lái)這只是React的入門門檻。真正的分水嶺在于你是否能清楚地解釋React在點(diǎn)擊一個(gè)按鈕之后從狀態(tài)變更到界面更新的完整過(guò)程。我習(xí)慣用一個(gè)類比來(lái)解釋這個(gè)過(guò)程render階段是編劇在寫劇本commit階段是導(dǎo)演把劇本拍成成片。React可以在編劇階段反復(fù)修改、取消、重新編排因?yàn)榇藭r(shí)還沒(méi)有對(duì)真實(shí)的DOM動(dòng)手可一旦進(jìn)入commit階段劇本就定稿了會(huì)真實(shí)地操作DOM、執(zhí)行副作用、觸發(fā)瀏覽器繪制。開(kāi)發(fā)者的絕大多數(shù)優(yōu)化空間都集中在“怎么讓編劇少寫無(wú)效劇本”這件事上。理解了這兩個(gè)階段很多困惑就會(huì)迎刃而解。比如為什么某些狀態(tài)更新會(huì)“丟失”為什么在useEffect里讀到的值是舊的為什么渲染了兩次這些問(wèn)題的答案都藏在render和commit的邊界里。我在整理rea筆記時(shí)很大一部分篇幅都是在記錄“邊界”二字——組件之間的邊界、副作用之間的邊界、優(yōu)化手段的邊界。2. React 18之后我對(duì)渲染模型的理解被重新洗了一遍2.1 自動(dòng)批處理默認(rèn)行為的改變很多人在不知不覺(jué)中被“拯救”React 18最容易被忽略的一個(gè)變化就是自動(dòng)批處理。在舊的版本里React只會(huì)在事件處理函數(shù)里合并同一個(gè)事件觸發(fā)的多次setState但在React 18里Promise、setTimeout、原生事件回調(diào)里的狀態(tài)更新都會(huì)被自動(dòng)合并。舉個(gè)例子const [count, setCount] useState(0); const [flag, setFlag] useState(false); function handleClick() { setTimeout(() { setCount(c c 1); setFlag(f !f); }, 100); }老版本里這段代碼會(huì)觸發(fā)兩次渲染React 18里只有一次。這個(gè)變化對(duì)性能是好消息但也帶來(lái)一個(gè)隱蔽的“坑”如果你在某個(gè)異步流程中間依賴了上一次更新的結(jié)果并且假設(shè)兩次setState之間有其他東西被同步執(zhí)行了那就可能出錯(cuò)。正確做法是別依賴中間狀態(tài)把每一次更新都看作獨(dú)立的提交。2.2 useTransition與useDeferredValue把“緊急”和“過(guò)渡”分開(kāi)React 18帶來(lái)了并發(fā)渲染的能力但對(duì)應(yīng)用層開(kāi)發(fā)者來(lái)說(shuō)最直觀的收獲是useTransition。我用一個(gè)搜索場(chǎng)景來(lái)理解它用戶在輸入框里打字是緊急更新必須立刻響應(yīng)而根據(jù)輸入去過(guò)濾一個(gè)幾千條的大列表則是可以延后的更新。const [isPending, startTransition] useTransition(); const [keyword, setKeyword] useState(); function handleChange(e) { setKeyword(e.target.value); startTransition(() { setFilteredList(filterListByKeyword(e.target.value)); }); }這個(gè)API的價(jià)值不在于“優(yōu)化了多少毫秒”而在于它重新定義了交互的優(yōu)先級(jí)讓用戶先看到輸入框的反饋再等待列表結(jié)果整個(gè)過(guò)程不會(huì)卡住輸入。很多人會(huì)把它和useDeferredValue搞混實(shí)踐中的差異在于useTransition包裹的是狀態(tài)更新邏輯useDeferredValue則是讓某個(gè)值的派生計(jì)算自動(dòng)降級(jí)。前者控制行為后者控制值——場(chǎng)景不同選擇也不同。2.3 Suspense的邊界能解決什么不能解決什么Suspense在React 18里開(kāi)始被越來(lái)越多地用于數(shù)據(jù)請(qǐng)求場(chǎng)景但它的邊界經(jīng)常被誤解。Suspense解決的是“等待異步資源時(shí)的UI降級(jí)”問(wèn)題——組件還沒(méi)就緒時(shí)顯示fallback就緒后顯示真實(shí)內(nèi)容。它不解決緩存問(wèn)題、不解決請(qǐng)求失敗后的重試策略、更不解決數(shù)據(jù)一致性。我在rea筆記里寫過(guò)一句提醒Suspense是UI層面的狀態(tài)機(jī)不是數(shù)據(jù)層面的解決方案。你仍然需要一個(gè)可靠的數(shù)據(jù)請(qǐng)求層來(lái)決定何時(shí)拋出Promise、何時(shí)展示數(shù)據(jù)、何時(shí)報(bào)錯(cuò)。把這兩件事分開(kāi)想架構(gòu)才會(huì)清晰。3. Hooks心智模型從“生命周期思維”切換到“副作用同步思維”3.1 useEffect的依賴地獄什么時(shí)候拆、什么時(shí)候合使用useEffect最容易踩的坑就是試圖讓它模擬類組件的生命周期。我見(jiàn)過(guò)太多代碼一個(gè)組件里只有一個(gè)巨大的useEffect里面同時(shí)做了數(shù)據(jù)請(qǐng)求、事件監(jiān)聽(tīng)、DOM操作和埋點(diǎn)上報(bào)依賴數(shù)組里塞了七八個(gè)值。這種寫法的問(wèn)題在于依賴數(shù)組里任何一個(gè)值變化整個(gè)副作用都會(huì)重新執(zhí)行而實(shí)際上每個(gè)子邏輯關(guān)心的依賴各不相同。正確的拆法不是按“執(zhí)行時(shí)機(jī)”拆而是按“數(shù)據(jù)依賴”拆——每個(gè)useEffect只關(guān)心一組相關(guān)變量互不干擾。// 反面例子一次useEffect做了三件事 useEffect(() { fetchData(); window.addEventListener(resize, handleResize); logPageView(); }, [params, isMobile, userId]); // 正面例子按依賴拆開(kāi) useEffect(() { fetchData(); }, [params, userId]); useEffect(() { window.addEventListener(resize, handleResize); return () window.removeEventListener(resize, handleResize); }, [isMobile]); useEffect(() { logPageView(); }, [params, userId]);在依賴數(shù)組這件事上我的經(jīng)驗(yàn)是兩句話依賴太少會(huì)導(dǎo)致閉包過(guò)期依賴太多會(huì)導(dǎo)致執(zhí)行頻次爆炸。所以要么按依賴分組拆開(kāi)要么用函數(shù)式更新來(lái)減少不必要的依賴。3.2 useMemo和useCallback的真正使用時(shí)機(jī)這兩個(gè)API可能是整個(gè)React體系里最容易被濫用的東西。很多人的理由是“用了總比不用安全”但事實(shí)恰恰相反無(wú)腦給每個(gè)函數(shù)和每個(gè)計(jì)算都包一層memo反而會(huì)增加比較開(kāi)銷和內(nèi)存負(fù)擔(dān)。我判斷是否使用useMemo的標(biāo)準(zhǔn)是這個(gè)計(jì)算的成本是否高到值得緩存比如一個(gè)需要遍歷數(shù)萬(wàn)條數(shù)據(jù)并排序的列表值得一個(gè)簡(jiǎn)單的字符串拼接不值得。useCallback同理只有當(dāng)它作為依賴傳遞給子組件并且子組件又被memo包裹時(shí)引用穩(wěn)定才有意義。否則useCallback只是在白白增加一層函數(shù)包裝。我給團(tuán)隊(duì)寫的規(guī)范里就有一條memo化的目標(biāo)不是“減少計(jì)算”而是“減少因引用變化引起的無(wú)關(guān)渲染”。一句話解釋清楚了大家就很少再亂用了。3.3 自定義Hook的封裝邊界自定義Hook很好用但并不意味著所有邏輯都應(yīng)該塞進(jìn)Hook里。我在復(fù)盤時(shí)發(fā)現(xiàn)一個(gè)規(guī)律和React渲染機(jī)制打交道的邏輯適合放進(jìn)Hook純業(yè)務(wù)計(jì)算的函數(shù)放在普通的函數(shù)模塊里更合適。我接手過(guò)某模擬項(xiàng)目里面有個(gè)很長(zhǎng)的自定義Hook里面包含了格式化日期、計(jì)算金額、校驗(yàn)手機(jī)號(hào)這類純工具方法。這些函數(shù)跟React一點(diǎn)關(guān)系都沒(méi)有卻被包在Hook里導(dǎo)致每次組件渲染都要重新創(chuàng)建一遍函數(shù)引用。把它們抽到獨(dú)立模塊后代碼沒(méi)有變得更復(fù)雜反而更容易單元測(cè)試。自定義Hook真正適合的場(chǎng)景是什么是那些需要useState、useEffect、useContext等React能力來(lái)串聯(lián)的邏輯封裝比如一個(gè)滾動(dòng)監(jiān)聽(tīng)Hook、一個(gè)表單校驗(yàn)Hook。把“數(shù)據(jù)邏輯”和“渲染邏輯”分開(kāi)是Hook封裝里最重要的一條線。4. 組件設(shè)計(jì)的決策鏈從受控到拆分我這么排優(yōu)先級(jí)4.1 受控與非受控第一層決策不該靠直覺(jué)每個(gè)React開(kāi)發(fā)者遲早都會(huì)遇到“這個(gè)輸入框的值到底誰(shuí)說(shuō)了算”的問(wèn)題。受控組件意味著值完全由React狀態(tài)控制非受控組件則讓DOM自己維護(hù)值React只是在需要的時(shí)候取一下。我的決策順序很簡(jiǎn)單如果值需要在組件外被讀取或修改就用受控如果只是表單內(nèi)部自己用毫不在意外面就用非受控。這個(gè)判斷標(biāo)準(zhǔn)幾乎覆蓋了所有場(chǎng)景。但真正的坑往往發(fā)生在“半受控”上。比如某同事寫的組件在半年前是受控的后來(lái)需求變了他忘了刪掉value綁定導(dǎo)致輸入框里敲不進(jìn)字。這類問(wèn)題排查起來(lái)特別浪費(fèi)時(shí)間所以我在代碼評(píng)審時(shí)總會(huì)專門盯一眼組件的受控狀態(tài)是否和props類型聲明保持一致。4.2 組件拆分的三個(gè)信號(hào)什么時(shí)候該拆組件很多人的標(biāo)準(zhǔn)是“看起來(lái)太長(zhǎng)就拆”。這個(gè)標(biāo)準(zhǔn)太模糊了。我總結(jié)出三個(gè)更具體的信號(hào)信號(hào)一組件內(nèi)部有超過(guò)兩組互不相關(guān)的state。說(shuō)明這些狀態(tài)分別服務(wù)于不同的UI區(qū)塊應(yīng)該拆。信號(hào)二渲染函數(shù)超過(guò)幾十行且邏輯層次復(fù)雜。不是說(shuō)要死記行數(shù)而是當(dāng)閱讀者需要上下滾動(dòng)好幾次才能看完結(jié)構(gòu)時(shí)就得拆。信號(hào)三某個(gè)子區(qū)塊只有在特定條件下才渲染且內(nèi)部有獨(dú)立交互邏輯。這種情況下把它拆成獨(dú)立組件能夠有效避免父組件的無(wú)關(guān)重渲染。拆組件不是為了代碼美觀而是為了收斂重渲染影響面——讓一個(gè)獨(dú)立區(qū)塊的更新不至于拖累其他區(qū)塊。4.3 狀態(tài)提升與狀態(tài)下沉不是只有“提升”一條路“狀態(tài)提升”這個(gè)詞大家都熟兩個(gè)兄弟組件要共享同一個(gè)狀態(tài)時(shí)把狀態(tài)放到最近的公共父組件里。但我在實(shí)踐中發(fā)現(xiàn)另一個(gè)方向同樣重要狀態(tài)下沉。所謂下沉就是當(dāng)父組件維護(hù)了一個(gè)只被某個(gè)子組件用到的狀態(tài)時(shí)把這個(gè)狀態(tài)搬到子組件里去。這樣做最直接的好處是父組件更新該狀態(tài)時(shí)不再觸發(fā)兄弟組件的重渲染。我見(jiàn)過(guò)好幾種設(shè)計(jì)把所有的狀態(tài)都放在頂層結(jié)果頂層組件一變化整棵組件樹都跟著刷新。這種“全提升”的策略不僅沒(méi)有解決問(wèn)題反而放大了性能開(kāi)銷。我的核心建議是先按“恰好夠用”決定狀態(tài)位置再根據(jù)實(shí)際渲染表現(xiàn)做調(diào)整。狀態(tài)管理的粒度不是越大越好而是越貼近使用者越好。5. 狀態(tài)管理選型的真實(shí)記錄我為什么放棄了一刀切的方案5.1 全局狀態(tài)不是默認(rèn)選項(xiàng)很多人一上來(lái)就引入Redux理由是“將來(lái)項(xiàng)目大了用得到”。這個(gè)理由站不住腳。全局狀態(tài)的核心成本在于一旦狀態(tài)放在全局任何一個(gè)組件更新它所有訂閱者都會(huì)被通知。這帶來(lái)的是更大的重渲染網(wǎng)絡(luò)和無(wú)形的約束成本。我判斷是否需要全局狀態(tài)就看兩件事這個(gè)狀態(tài)是否被大量跨層級(jí)組件共享這個(gè)狀態(tài)是否需要跨頁(yè)面持久主題模式、登錄用戶信息、當(dāng)前語(yǔ)言配置屬于這類而某個(gè)彈窗當(dāng)前是否打開(kāi)、某個(gè)表單正在編輯的值都不屬于。5.2 服務(wù)端狀態(tài)和客戶端狀態(tài)得分開(kāi)管我在狀態(tài)管理上做過(guò)一次很重要的重構(gòu)起因是某模擬項(xiàng)目的組件內(nèi)部大面積使用Redux來(lái)管理從接口拿到的數(shù)據(jù)。每次進(jìn)入頁(yè)面要手動(dòng)dispatch一個(gè)拉數(shù)據(jù)動(dòng)作處理loading、error、success三種狀態(tài)還要處理緩存重復(fù)請(qǐng)求。代碼數(shù)量龐大不說(shuō)邏輯還容易出錯(cuò)。那次之后我得出了一個(gè)明確結(jié)論服務(wù)端數(shù)據(jù)的狀態(tài)管理和客戶端交互狀態(tài)的管理是完全不同的兩類問(wèn)題。前者要解決的是緩存、失效、重試、去重、并發(fā)請(qǐng)求的合并這類問(wèn)題用專門的請(qǐng)求庫(kù)能省下至少一半的代碼。后者才是傳統(tǒng)全局狀態(tài)庫(kù)的主場(chǎng)。5.3 輕量方案的勝利狀態(tài)管理不一定需要重型方案。我在多個(gè)模擬項(xiàng)目里嘗試過(guò)輕量方案之后深刻體會(huì)到對(duì)于中小型項(xiàng)目來(lái)說(shuō)一個(gè)只有幾十行API的狀態(tài)庫(kù)已經(jīng)能覆蓋絕大多數(shù)需求開(kāi)發(fā)體驗(yàn)遠(yuǎn)遠(yuǎn)好于寫一堆樣板代碼的遠(yuǎn)古方案。而Redux的定位更像是大型項(xiàng)目里需要強(qiáng)約束、時(shí)間旅行調(diào)試、復(fù)雜中間件場(chǎng)景下的選擇。我的建議是選型從輕的開(kāi)始當(dāng)項(xiàng)目真的暴露出約束不足、邏輯混亂或調(diào)試?yán)щy時(shí)再升級(jí)也不遲。很多團(tuán)隊(duì)不是“選錯(cuò)了方案”而是“根本不需要那么重的方案”。6. 性能優(yōu)化我踩過(guò)的坑證明優(yōu)化不是調(diào)參而是消除無(wú)效渲染6.1 React.memo的邊界和反模式React.memo確實(shí)能阻止因父組件重渲染而觸發(fā)的子組件重渲染但它有一個(gè)重要的前提條件子組件接收的props必須是穩(wěn)定引用。如果props里有每次渲染都會(huì)重建的對(duì)象或函數(shù)memo就完全失效了。更值得警惕的是“全員memo”的反模式。某個(gè)項(xiàng)目里曾經(jīng)把所有組件都包了一層memo結(jié)果代碼可讀性下降大量函數(shù)被改造成useCallback只是為了迎合memo的比較邏輯而實(shí)際的渲染性能沒(méi)有明顯提升。原因很簡(jiǎn)單這些組件本來(lái)渲染成本就不高parent的重渲染本身就很快。React.memo真正適合的是那些渲染成本較高且父組件頻繁更新的葉節(jié)點(diǎn)組件比如一個(gè)大表格里的行、一個(gè)大列表里的項(xiàng)。用表格來(lái)看會(huì)更清楚場(chǎng)景是否建議用memo父組件高頻更新子組件渲染成本高建議子組件經(jīng)常接收新的props并觸發(fā)更新請(qǐng)求建議組件很小渲染不到1ms不建議組件的props對(duì)象每次都會(huì)變化不建議memo無(wú)效6.2 列表渲染的性能陷阱key只是第一道門列表是React里最普遍的性能黑洞。很多人知道用key卻只停留在“不要用index”的程度。真正的問(wèn)題在于key的作用是幫React識(shí)別“哪個(gè)組件發(fā)生了改變”它必須能穩(wěn)定地代表一條數(shù)據(jù)的身份。用index做key會(huì)出現(xiàn)什么后果假設(shè)一個(gè)列表可以勾選并刪除第一項(xiàng)React會(huì)認(rèn)為原來(lái)的第一項(xiàng)還在只是內(nèi)容變了于是復(fù)用了舊的DOM和狀態(tài)導(dǎo)致勾選狀態(tài)錯(cuò)亂。這是經(jīng)典Bug很多人在排查半天之后才想起是不是key出了問(wèn)題。除了key之外列表性能還取決于分頁(yè)、虛擬滾動(dòng)和列表項(xiàng)自身的memo。如果列表項(xiàng)本身是一個(gè)大組件每次輸入一個(gè)新字符都要整列重新渲染這種體驗(yàn)在數(shù)據(jù)量達(dá)到幾百條時(shí)就會(huì)明顯變差。6.3 Profiler在什么時(shí)候能幫你我不建議一開(kāi)始就打開(kāi)性能工具盯著數(shù)字看因?yàn)楹芏鄡?yōu)化不是通過(guò)“看”發(fā)現(xiàn)的而是通過(guò)“邏輯分析”發(fā)現(xiàn)的。但當(dāng)你已經(jīng)完成代碼層面的精簡(jiǎn)仍然感覺(jué)界面卡頓、摸不準(zhǔn)瓶頸在哪個(gè)組件時(shí)Profiler能幫你精準(zhǔn)定位。React Profiler的使用方法我總結(jié)為三步先記錄一段有問(wèn)題的交互觀察哪棵子樹渲染耗時(shí)最長(zhǎng)再查看這個(gè)子樹是否頻繁渲染、是否每次都由父組件拖動(dòng)最后根據(jù)結(jié)果決定優(yōu)化手段包memo、拆組件、下沉狀態(tài)還是降低渲染成本。用數(shù)據(jù)替代感覺(jué)是優(yōu)化里最重要的一步。7. 那些讓我調(diào)試到深夜的React陷阱7.1 閉包陷阱為什么setTimeout里讀到的state永遠(yuǎn)是舊的這個(gè)問(wèn)題幾乎每個(gè)人都遇到過(guò)在useEffect里設(shè)置一個(gè)定時(shí)器定時(shí)器回調(diào)里讀取某個(gè)state發(fā)現(xiàn)讀到的一直是初始值或舊值而不是最新值。原因在于函數(shù)組件每次渲染都會(huì)生成一個(gè)新的閉包定時(shí)器捕獲的是它創(chuàng)建時(shí)刻那個(gè)渲染批次的狀態(tài)。解決方案有三種一是把依賴寫進(jìn)useEffect的數(shù)組讓定時(shí)器在依賴變化時(shí)重建二是使用函數(shù)式更新讓React在更新階段計(jì)算值三是用useRef保存最新值因?yàn)閞ef總是同一個(gè)對(duì)象永遠(yuǎn)能讀到當(dāng)前值。const countRef useRef(0); useEffect(() { countRef.current count; }, [count]); useEffect(() { const timer setInterval(() { // 這里通過(guò) countRef.current 讀取最新值 console.log(countRef.current); }, 1000); return () clearInterval(timer); }, []);7.2 Key值亂用的后果不是報(bào)錯(cuò)是狀態(tài)錯(cuò)亂key值亂用最坑的地方在于它通常不報(bào)錯(cuò)只是表現(xiàn)出一些匪夷所思的界面行為。比如切換Tab后表單里還有上一個(gè)Tab的輸入值刪掉某一行后下一行的勾選狀態(tài)丟了。這些問(wèn)題的核心都是React復(fù)用了不應(yīng)該復(fù)用的組件實(shí)例。解決的思路很簡(jiǎn)單key必須和業(yè)務(wù)數(shù)據(jù)的唯一標(biāo)識(shí)綁定。如果數(shù)據(jù)沒(méi)有唯一ID可以用組合字段生成一個(gè)穩(wěn)定的key但千萬(wàn)別用數(shù)組下標(biāo)。這個(gè)原則在任何列表里都適用。7.3 StrictMode雙調(diào)用不是Bug是保護(hù)機(jī)制StrictMode下useEffect在開(kāi)發(fā)環(huán)境中會(huì)執(zhí)行兩次第一次執(zhí)行之后清理函數(shù)也會(huì)被調(diào)用。很多人以為是自己代碼寫錯(cuò)了在搜索框里瘋狂輸入“why twice”浪費(fèi)了大量時(shí)間。這個(gè)設(shè)計(jì)的真實(shí)意圖是幫助開(kāi)發(fā)者提前暴露副作用問(wèn)題如果組件的副作用沒(méi)有正確實(shí)現(xiàn)清理雙調(diào)用就會(huì)暴露錯(cuò)亂的痕跡。比如一個(gè)全局事件監(jiān)聽(tīng)沒(méi)有在清理函數(shù)里移除StrictMode模式下會(huì)產(chǎn)生重復(fù)執(zhí)行。換句話說(shuō)這既是“找茬”也是一次免費(fèi)的質(zhì)量檢查。8. 服務(wù)端渲染與元框架React實(shí)踐的自然延伸8.1 客戶端渲染的代價(jià)是什么純客戶端渲染會(huì)讓首頁(yè)經(jīng)歷一個(gè)空白到內(nèi)容出現(xiàn)的等待過(guò)程。頁(yè)面要先下載JS、解析JS、執(zhí)行渲染才能顯示實(shí)際內(nèi)容。對(duì)于交互復(fù)雜的后臺(tái)系統(tǒng)這個(gè)體驗(yàn)還能忍但對(duì)于內(nèi)容型頁(yè)面或?qū)κ灼了俣让舾械穆涞仨?yè)這就有點(diǎn)說(shuō)不過(guò)去了。服務(wù)端渲染的直觀收益是首屏HTML提前渲染好用戶第一時(shí)間看到內(nèi)容。它的代價(jià)是服務(wù)器需要承擔(dān)更多渲染壓力部署鏈路也變得更復(fù)雜。所以它不一定適合所有項(xiàng)目決策的關(guān)鍵在于這個(gè)頁(yè)面的首屏速度到底重不重要。8.2 流式渲染Suspense在服務(wù)端的真正價(jià)值React 18的流式渲染讓服務(wù)端可以分塊輸出HTML配合Suspense哪個(gè)區(qū)塊的數(shù)據(jù)先就緒就先輸出哪個(gè)。這意味著不用再等頁(yè)面里最慢的那個(gè)接口返回才開(kāi)始渲染用戶會(huì)先看到頁(yè)面主體骨架再逐步填充內(nèi)容區(qū)塊。這個(gè)模式的好處是體驗(yàn)平滑壞處是調(diào)試復(fù)雜度增加。我在某個(gè)模擬項(xiàng)目里踩過(guò)坑某個(gè)區(qū)塊的Suspense fallback一直不消失排查到最后發(fā)現(xiàn)是數(shù)據(jù)請(qǐng)求Promise從未resolve。這說(shuō)明流式渲染并不能解決全部煩惱它只是把一個(gè)長(zhǎng)等待切成了若干個(gè)短等待。8.3 元框架選擇的核心考量關(guān)于元框架的選擇我給團(tuán)隊(duì)的建議是看部署環(huán)境、看團(tuán)隊(duì)技術(shù)棧、看SEO需求、看互動(dòng)復(fù)雜度四件事想清楚再動(dòng)手。不必盲目追求最新因?yàn)樾驴蚣芡馕吨蟮男闹秦?fù)擔(dān)和更多不成熟的周邊工具。在選擇時(shí)先跑一個(gè)小Demo驗(yàn)證整個(gè)數(shù)據(jù)獲取和路由的鏈路是否順手再?zèng)Q定是否遷移。另外一個(gè)容易被忽略的因素是團(tuán)隊(duì)已有的運(yùn)維能力。選擇哪套服務(wù)端方案不只是前端的決策它還牽動(dòng)服務(wù)器配置、日志監(jiān)控、發(fā)布流程等基礎(chǔ)設(shè)施。別只看官網(wǎng)Demo好看。9. 團(tuán)隊(duì)落地React實(shí)踐的經(jīng)驗(yàn)沉淀9.1 代碼規(guī)范該管什么可讀性大于炫技我在整理團(tuán)隊(duì)規(guī)范時(shí)重點(diǎn)關(guān)注四個(gè)維度組件props的命名一致性、副作用代碼必須包含清理邏輯、memo和useCallback的使用必須附帶注釋說(shuō)明理由、每次狀態(tài)提升或下沉必須明確寫出原因。這四條不是為了限制自由而是為了降低后來(lái)者的閱讀成本。最怕的是團(tuán)隊(duì)里出現(xiàn)一種代碼每個(gè)函數(shù)都包了useCallback每個(gè)計(jì)算都塞了useMemo但沒(méi)有人說(shuō)得清為什么。這種代碼的維護(hù)成本極高因?yàn)樗选皟?yōu)化痕跡”留在了每一行卻把“優(yōu)化理由”藏了起來(lái)。9.2 從基礎(chǔ)組件到業(yè)務(wù)組件的分層結(jié)構(gòu)我把組件分為三層基礎(chǔ)UI組件層、業(yè)務(wù)組件層、頁(yè)面組件層。基礎(chǔ)UI組件只負(fù)責(zé)接收props渲染界面不依賴任何業(yè)務(wù)數(shù)據(jù)業(yè)務(wù)組件在基礎(chǔ)組件之上綁定具體的數(shù)據(jù)來(lái)源和交互邏輯頁(yè)面組件則負(fù)責(zé)組合業(yè)務(wù)組件、管理路由參數(shù)和頁(yè)面級(jí)狀態(tài)。這種分層的直接收益是基礎(chǔ)組件可以獨(dú)立測(cè)試、跨項(xiàng)目復(fù)用業(yè)務(wù)組件可以獨(dú)立調(diào)試、獨(dú)立響應(yīng)需求變化。我在多個(gè)模擬項(xiàng)目的重構(gòu)里嘗到了這個(gè)結(jié)構(gòu)的甜頭尤其是當(dāng)需求方頻繁調(diào)整頁(yè)面布局時(shí)基礎(chǔ)組件層幾乎不需要?jiǎng)印?.3 新人上手React的學(xué)習(xí)路徑建議很多新人一上來(lái)就學(xué)習(xí)全套工具鏈類型系統(tǒng)、狀態(tài)庫(kù)、路由庫(kù)、CSS方案、構(gòu)建工具結(jié)果一頭霧水。我建議的學(xué)習(xí)路徑是先吃透JavaScript/TypeScript基礎(chǔ)再學(xué)React本身的組件和渲染模型先寫原生組件撐起一個(gè)小頁(yè)面然后逐步引入工程化工具最后才是狀態(tài)庫(kù)和元框架。這個(gè)順序的核心邏輯是讓每一步的學(xué)習(xí)都能解釋之前遇到的一個(gè)問(wèn)題。而不是反過(guò)來(lái)為了用某個(gè)工具而學(xué)習(xí)某個(gè)工具。我見(jiàn)過(guò)不少新人學(xué)完了所有工具反而說(shuō)不清楚“為什么需要這個(gè)工具”。工具是為問(wèn)題服務(wù)的先遇到問(wèn)題再解決問(wèn)題知識(shí)才是自己的。10. 最后想說(shuō)的幾點(diǎn)體會(huì)整理這堆筆記的過(guò)程其實(shí)也是我自己反復(fù)“考古”的過(guò)程。很多時(shí)候把代碼寫出來(lái)只需要幾分鐘但搞清楚它為什么有效、什么時(shí)候失效卻需要幾個(gè)晚上。rea這三個(gè)字母對(duì)我來(lái)說(shuō)已經(jīng)從“我的筆記代號(hào)”變成了一個(gè)思考習(xí)慣每次做技術(shù)決策先問(wèn)自己一句“這個(gè)選擇的邊界是什么、代價(jià)是什么”。如果你也在維護(hù)自己的一套實(shí)踐筆記我建議你多記錄“決策原因”而不是“API用法”。API會(huì)變?cè)虿粫?huì)。下次當(dāng)你面對(duì)一個(gè)看似相同的Bug卻換了新的場(chǎng)景時(shí)真正能幫到你的正是那些當(dāng)初寫下來(lái)的判斷依據(jù)。最后分享一個(gè)小習(xí)慣每隔一段時(shí)間把最近寫過(guò)的組件代碼翻出來(lái)用“如果現(xiàn)在重寫會(huì)怎么設(shè)計(jì)”的眼光重新審視一遍。這個(gè)過(guò)程不一定要真的改代碼但它能讓你看見(jiàn)自己思維模型的成長(zhǎng)軌跡。React生態(tài)發(fā)展很快但真正值得反復(fù)琢磨的永遠(yuǎn)是那幾條樸素的原則——理解渲染、劃清邊界、管理副作用。愿你少踩幾個(gè)我踩過(guò)的坑。