每個(gè)React項(xiàng)目都會(huì)在第二個(gè)月遇到同一個(gè)岔路口。prop drilling讓人崩潰，有人說(shuō)"得搞狀態(tài)管理了"，接下來(lái)兩天就是一場(chǎng)觀點(diǎn)混戰(zhàn)：Redux因?yàn)閳F(tuán)隊(duì)熟悉，Zustand因?yàn)橛腥丝戳似┛停珻ontext因?yàn)?這不是內(nèi)置的嗎？"

真正的錯(cuò)誤不是選錯(cuò)工具，而是沒(méi)意識(shí)到這三樣?xùn)|西解決的問(wèn)題壓根不一樣。

Context API是傳輸機(jī)制，不是狀態(tài)庫(kù)。它讓值跨組件樹(shù)傳遞，不用層層props往下傳。僅此而已。Context里的"狀態(tài)"就是你在provider旁邊寫(xiě)的useState。值一變，所有consumer都重渲染。沒(méi)有selector層，沒(méi)有批量更新，沒(méi)有調(diào)試工具。它是根電線，不是倉(cāng)庫(kù)。

Redux是單一倉(cāng)庫(kù)，更新可預(yù)測(cè)、可追溯。一個(gè)reducer，一個(gè)數(shù)據(jù)源，每次改動(dòng)走同一條管道，你能回放整個(gè)流程。時(shí)間旅行調(diào)試是設(shè)計(jì)自帶的功能。

你記憶中的Redux大概不是現(xiàn)在人寫(xiě)的Redux。action types、action creators、reducer里的switch語(yǔ)句、connect高階組件、mapStateToProps——這些讓Redux成梗的樣板代碼，都是老黃歷了。Redux Toolkit（RTK）才是現(xiàn)在的寫(xiě)法。創(chuàng)傷是真的，樣板代碼是假的，這個(gè)認(rèn)知差讓大多數(shù)"Redux vs X"對(duì)比都失了公允。

Zustand是包裹在hook里的倉(cāng)庫(kù)。沒(méi)有provider，沒(méi)有reducer，沒(méi)有action。你定義一個(gè)store，用selector讀取，直接調(diào)方法更新。更像"住在組件外面的useState"，而非Flux架構(gòu)。

同一個(gè)簡(jiǎn)單例子，三種寫(xiě)法，體感差距一目了然：

Context API需要createContext、Provider包裹、useContext取值，setUser藏在context對(duì)象里。Redux Toolkit用createSlice定義slice，configureStore創(chuàng)建store，useSelector讀值，dispatch觸發(fā)更新。Zustand直接create一個(gè)hook，里面放state和setter，用selector精準(zhǔn)訂閱，調(diào)用即更新。

選型看場(chǎng)景：跨組件傳值且更新不頻繁，Context夠用。需要可預(yù)測(cè)的狀態(tài)流、調(diào)試能力、中間件生態(tài)，Redux Toolkit。想要極簡(jiǎn)API、無(wú)樣板、靈活組合，Zustand。

沒(méi)有銀彈，只有錯(cuò)把螺絲刀當(dāng)錘子的人。