你明明點了登錄，購物車卻顯示未登錄。Redux DevTools里赫然躺著兩個store實例——這不是幻覺，是Module Federation與Next.js混用時最隱蔽的bug。

幽靈現(xiàn)象：登錄狀態(tài)去哪兒了

典型場景：Auth遠程組件（純React）dispatch了setIsLoggedIn(true)，Products遠程組件（Next.js）用useAppSelector讀取，返回卻是false。

打開Redux DevTools，真相浮出水面：Auth創(chuàng)建了一個store，Products創(chuàng)建了另一個。每個遠程都在自己的副本里玩，狀態(tài)互不相通。

問題的根源在于Module Federation的共享機制。當React遠程通過ModuleFederationPlugin嵌入Next.js宿主（NextFederationPlugin），默認情況下每個遠程會獨立初始化依賴包。Redux store不是天然單例，而是"每個bundle一個"。

宿主和遠程的構(gòu)建工具鏈差異加劇了混亂：React遠程用webpack，Next.js遠程用自身的next.config.js配置。兩套配置若未對齊共享聲明，同一份@myapp/store代碼會被打包多次，運行時變成兩個獨立對象。

單例契約：@myapp/store包的設(shè)計

解決方案是一個聯(lián)邦化的Redux單例。核心架構(gòu)：獨立的@myapp/store包，宿主導(dǎo)入一次、創(chuàng)建store、用Provider包裹應(yīng)用。所有遠程從這個包導(dǎo)入useSelector和useDispatch，Module Federation運行時保證它們拿到的是宿主實例，而非全新副本。

包內(nèi)結(jié)構(gòu)需要完整輸出：configureStore配置、各slice定義、重新導(dǎo)出的react-redux基礎(chǔ)鉤子。這不是簡單的類型共享，而是運行時對象的唯一性保證。

關(guān)鍵組件是ClientReduxProvider，且必須標記ssr: false。如果在_app.tsx頂部直接導(dǎo)入store，服務(wù)端構(gòu)建會崩潰——Redux依賴的瀏覽器API（如window）在Node環(huán)境不存在。動態(tài)導(dǎo)入+客戶端限定是生存底線。

配置層面，宿主next.config.js和每個遠程的webpack配置必須同步聲明共享塊：singleton: true鎖定單例，strictVersion強制版本一致。遺漏任一標志，運行時協(xié)商就會失敗。

五步協(xié)商：Module Federation如何決定用誰的store

運行時機制比想象中復(fù)雜。當遠程組件加載時，Module Federation執(zhí)行五步談判：注冊共享依賴、動態(tài)導(dǎo)入嘗試、版本匹配檢查、實例復(fù)用決策、最終掛載。

版本匹配是常見陷阱。@myapp/store若在不同遠程中有細微版本差異（如1.2.3 vs 1.2.4），strictVersion: true會強制報錯，strictVersion: false則可能靜默創(chuàng)建多個實例。生產(chǎn)環(huán)境建議鎖定精確版本，用workspace或monorepo工具統(tǒng)一管控。

實際代碼中，Auth遠程（React）dispatch setIsLoggedIn后，Products遠程（Next.js）能實時讀取selectAccessToken——前提是DevTools里只有一個store。這種跨技術(shù)棧的狀態(tài)同步，正是聯(lián)邦架構(gòu)的價值所在。

每個遠程仍需保留自己的ClientReduxProvider，但僅用于獨立開發(fā)模式。生產(chǎn)環(huán)境下，這些Provider會被宿主的實例覆蓋，形成"開發(fā)時隔離、運行時統(tǒng)一"的雙層結(jié)構(gòu)。

SSR陷阱：服務(wù)端渲染與聯(lián)邦狀態(tài)的生死沖突

Next.js的SSR與聯(lián)邦化Redux存在根本性張力。服務(wù)端無法預(yù)知遠程組件的加載時機，更無法在HTML生成階段完成跨遠程的狀態(tài)協(xié)商。

正確策略是跳過聯(lián)邦狀態(tài)的SSR，客戶端掛載后再hydrate。具體實現(xiàn)：ClientReduxProvider包裹的組件在服務(wù)端渲染為占位，瀏覽器執(zhí)行時動態(tài)拉取遠程、重建store、恢復(fù)狀態(tài)。首屏可能閃爍，但避免了hydration mismatch導(dǎo)致的崩潰。

這種狀態(tài)決策需要矩陣化思考：聯(lián)邦store適合跨遠程共享的認證狀態(tài)、全局主題；useState保留給純本地UI；URL search params處理可分享的可篩選狀態(tài)；TanStack Query接管服務(wù)端緩存。沒有銀彈，只有邊界清晰的職責劃分。

80% bug的終極診斷：數(shù)store個數(shù)

作者給出的調(diào)試黃金法則極其直接：打開Redux DevTools，數(shù)store數(shù)量。多于一個，說明單例協(xié)商失敗——檢查共享配置的singleton: true、版本聲明、包名拼寫。

修復(fù)這個之前，其他調(diào)試都是浪費時間。無論掛載多少遠程，DevTools里必須只有一個store。

原文列出的7個gotcha覆蓋幾乎所有"狀態(tài)不傳播"場景：共享塊拼寫錯誤、版本范圍沖突、Provider嵌套順序、動態(tài)導(dǎo)入時機、構(gòu)建緩存污染、monorepo符號鏈接問題、運行時版本回退策略。每個都是血淚踩坑史。

這篇技術(shù)指南的完整代碼示例展示了從configureStore到生產(chǎn)配置的完整鏈路。對于正在混用React與Next.js微前端的團隊，這不是"最佳實踐"的錦上添花，而是阻止狀態(tài)分裂的必需基礎(chǔ)設(shè)施。