微前端登录态"幽灵"：一个store为何变两个

你明明点了登录，购物车却显示未登录。Redux DevTools里赫然躺着两个store实例——这不是幻觉，是Module Federation与Next.js混用时最隐蔽的bug。

幽灵现象：登录状态去哪儿了

典型场景：Auth远程组件（纯React）dispatch了setIsLoggedIn(true)，Products远程组件（Next.js）用useAppSelector读取，返回却是false。

打开Redux DevTools，真相浮出水面：Auth创建了一个store，Products创建了另一个。每个远程都在自己的副本里玩，状态互不相通。

问题的根源在于Module Federation的共享机制。当React远程通过ModuleFederationPlugin嵌入Next.js宿主（NextFederationPlugin），默认情况下每个远程会独立初始化依赖包。Redux store不是天然单例，而是"每个bundle一个"。

宿主和远程的构建工具链差异加剧了混乱：React远程用webpack，Next.js远程用自身的next.config.js配置。两套配置若未对齐共享声明，同一份@myapp/store代码会被打包多次，运行时变成两个独立对象。

单例契约：@myapp/store包的设计

解决方案是一个联邦化的Redux单例。核心架构：独立的@myapp/store包，宿主导入一次、创建store、用Provider包裹应用。所有远程从这个包导入useSelector和useDispatch，Module Federation运行时保证它们拿到的是宿主实例，而非全新副本。

包内结构需要完整输出：configureStore配置、各slice定义、重新导出的react-redux基础钩子。这不是简单的类型共享，而是运行时对象的唯一性保证。

关键组件是ClientReduxProvider，且必须标记ssr: false。如果在_app.tsx顶部直接导入store，服务端构建会崩溃——Redux依赖的浏览器API（如window）在Node环境不存在。动态导入+客户端限定是生存底线。

配置层面，宿主next.config.js和每个远程的webpack配置必须同步声明共享块：singleton: true锁定单例，strictVersion强制版本一致。遗漏任一标志，运行时协商就会失败。

五步协商：Module Federation如何决定用谁的store

运行时机制比想象中复杂。当远程组件加载时，Module Federation执行五步谈判：注册共享依赖、动态导入尝试、版本匹配检查、实例复用决策、最终挂载。

版本匹配是常见陷阱。@myapp/store若在不同远程中有细微版本差异（如1.2.3 vs 1.2.4），strictVersion: true会强制报错，strictVersion: false则可能静默创建多个实例。生产环境建议锁定精确版本，用workspace或monorepo工具统一管控。

实际代码中，Auth远程（React）dispatch setIsLoggedIn后，Products远程（Next.js）能实时读取selectAccessToken——前提是DevTools里只有一个store。这种跨技术栈的状态同步，正是联邦架构的价值所在。

每个远程仍需保留自己的ClientReduxProvider，但仅用于独立开发模式。生产环境下，这些Provider会被宿主的实例覆盖，形成"开发时隔离、运行时统一"的双层结构。

SSR陷阱：服务端渲染与联邦状态的生死冲突

Next.js的SSR与联邦化Redux存在根本性张力。服务端无法预知远程组件的加载时机，更无法在HTML生成阶段完成跨远程的状态协商。

正确策略是跳过联邦状态的SSR，客户端挂载后再hydrate。具体实现：ClientReduxProvider包裹的组件在服务端渲染为占位，浏览器执行时动态拉取远程、重建store、恢复状态。首屏可能闪烁，但避免了hydration mismatch导致的崩溃。

这种状态决策需要矩阵化思考：联邦store适合跨远程共享的认证状态、全局主题；useState保留给纯本地UI；URL search params处理可分享的可筛选状态；TanStack Query接管服务端缓存。没有银弹，只有边界清晰的职责划分。

80% bug的终极诊断：数store个数

作者给出的调试黄金法则极其直接：打开Redux DevTools，数store数量。多于一个，说明单例协商失败——检查共享配置的singleton: true、版本声明、包名拼写。

修复这个之前，其他调试都是浪费时间。无论挂载多少远程，DevTools里必须只有一个store。

原文列出的7个gotcha覆盖几乎所有"状态不传播"场景：共享块拼写错误、版本范围冲突、Provider嵌套顺序、动态导入时机、构建缓存污染、monorepo符号链接问题、运行时版本回退策略。每个都是血泪踩坑史。

这篇技术指南的完整代码示例展示了从configureStore到生产配置的完整链路。对于正在混用React与Next.js微前端的团队，这不是"最佳实践"的锦上添花，而是阻止状态分裂的必需基础设施。