React 子应用接入 qiankun `initGlobalState` 的状态管理方案对比

背景

在 qiankun 微前端中，主应用通过 initGlobalState 创建全局状态，子应用通过 onGlobalStateChange 监听并响应变化，通过 setGlobalState 回写。React 子应用需要将这一外部状态同步为内部可用的响应式数据，并在组件间共享。

React 生态提供了多种状态管理方案，均可作为桥接层。本文分析五种主流方式：

• React Context + useState/useReducer
• Redux / Redux Toolkit
• Zustand
• MobX
• Jotai / Recoil

各方案优劣分析

1. React Context + useState/useReducer

实现方式
在子应用入口（如 mount 函数）创建 Context，通过 useState 或 useReducer 管理全局状态，订阅 onGlobalStateChange 并更新 state，通过 dispatch 或 setState 调用 setGlobalState 回写主应用。

✅ 优势

• 零依赖：React 内置 API，不增加包体积，适合极简子应用。
• 简单直观：对于少量全局状态，逻辑清晰，无额外学习成本。
• 与 qiankun 同步灵活：可在 Context Provider 中封装监听逻辑，后代组件通过 useContext 直接消费。

❌ 劣势

• 性能隐患：Context 的值变化会导致所有消费者组件重新渲染，即使只使用了部分状态，需手动拆分 Context 或用 useMemo 优化。
• 无 DevTools 支持：无法追踪状态变更历史，调试困难。
• 缺乏结构约束：容易演变成“全局大对象”，团队协作时易造成混乱。
• 逻辑复用性差：同步 qiankun 的粘合代码散落在入口文件或自定义 Hook 中，不够内聚。

适用场景：只有极少量全局配置（如用户信息、主题）且组件树不深的微型子应用。

2. Redux / Redux Toolkit

实现方式
创建 Redux store，定义 slice 存放从 qiankun 接收的全局状态。在 mount 时订阅变化并 dispatch 更新 store；通过 thunk 或自定义 action 调用 setGlobalState。

✅ 优势

• 成熟的 DevTools：时间旅行、状态快照，方便复杂数据流调试。
• 强约束与可预测性：单一数据源，通过 reducer 纯函数更新，适合大型团队。
• 中间件生态：支持持久化（redux-persist）、异步逻辑（redux-thunk/saga）等。
• 精准渲染：结合 useSelector 或 connect，只有使用了相关状态的组件才会重渲染。

❌ 劣势

• 模板代码多：即使 Redux Toolkit 简化了配置，仍需要定义 slice、action、reducer，对小应用而言过度设计。
• 包体积较大：redux + react-redux + toolkit 整体较重。
• 同步逻辑需精心设计：需避免 “qiankun 全局状态 ↔ Redux” 双向更新导致死循环。
• 学习曲线：对新手有一定门槛。

适用场景：已深度使用 Redux 的遗留项目，或状态逻辑极其复杂、需中间件支持的大型子应用。

3. Zustand

实现方式
创建一个 Zustand store，使用 set 更新状态。在 mount 时调用 onGlobalStateChange 的回调直接执行 set 同步状态；通过 store 的 action 调用 setGlobalState。

✅ 优势

• 极致轻量：gzipped ~1KB，无 boilerplate。
• 简洁的 API：基于 Hook，状态选择器支持精确渲染，性能优秀。
• 无需 Provider：store 创建后直接通过 Hook 在组件中使用，减少组件树嵌套。
• 与 qiankun 结合自然：同步逻辑可完全封装在 store 创建函数内，对外暴露纯净的 Hook（如 useGlobalStore）。
• 支持中间件：持久化、DevTools、immer 等可选插件。

❌ 劣势

• 非官方方案：社区维护，但版本稳定且广泛使用。
• 调试依赖插件：需手动接入 Redux DevTools 才能查看状态历史。
• 学习成本低但需适应：对习惯 Redux 的开发者可能需要调整心智模型（不可变更新需注意）。

适用场景：绝大多数 React 子应用，从微应用到中大型应用均能胜任，且与 qiankun 桥接成本最低。

4. MobX

实现方式
创建 observable 对象/类，通过 makeAutoObservable 封装从 qiankun 传入的状态。在 mount 时调用 onGlobalStateChange 更新 observable 属性，通过 action 调用 setGlobalState。

✅ 优势

• 响应式精确更新：依赖自动追踪，只有实际读取了变化数据的组件才会重渲染。
• 代码简洁：无需大量模板，状态修改直观（直接赋值）。
• 面向对象/类自然：适合使用 class 组织状态的团队。
• 成熟生态：mobx-react-lite 的 observer HOC/Hook 使用方便。

❌ 劣势

• 魔法性较强：Proxy/defineProperty 的自动跟踪可能让调试变得困难（需严格遵循 action 规范）。
• 与 qiankun 单向数据流融合需小心：修改全局状态时容易绕开 setGlobalState 直接改动对象，破坏数据流。
• 包体积中等：MobX 约 16KB gzipped，加上 mobx-react 更大。
• 学习曲线：对不熟悉响应式编程的开发者有一定挑战。

适用场景：团队熟悉 MobX 或需要高度自动化的响应式更新，且状态结构较为扁平、变化频繁。

5. Jotai / Recoil

实现方式
定义原子（atom）代表 qiankun 传入的各项状态。在 mount 时通过 onGlobalStateChange 更新 atom 的值；组件内通过 useAtom 读写，写操作时同步调用 setGlobalState。

✅ 优势

• 原子化状态：每个状态独立管理，可实现组件级的精确更新，性能最佳。
• 无 Provider 负担：Jotai 无需 Provider，Recoil 需根组件包裹但性能优化优异。
• 组合能力强：可派生状态，天然适合 qiankun 的扁平全局状态拆分。
• 简洁直观：Jotai API 类似 useState，学习成本极低。

❌ 劣势

• 库仍在发展中：Jotai 相对年轻，Recoil 实验性质略重（Facebook 不再积极维护）。
• 调试支持较弱：Jotai 需第三方 DevTools，Recoil 有自带但稳定性一般。
• 原子过多导致碎片化：如果全局状态字段非常多，管理众多 atom 可能变得分散。
• 回写需手动封装：在 setter 中同步调用 setGlobalState 的逻辑需统一处理，否则容易遗漏。

适用场景：状态字段独立且量少、追求极致精确渲染的现代 React 子应用，尤其是使用 Jotai 的新项目。

核心对比总结

推荐选择策略

为什么 Zustand 是首选？

• 桥接成本最低：可在 create 函数内一次性完成监听、同步与回写，暴露的 Hook 只有状态和方法，组件完全无感于 qiankun 存在。
• 无 Provider 污染：避免因为状态管理而改变组件树结构。
• 扩展性：需要中间件时随时添加（如 devtools、persist），无需大改架构。

核心原则一致：无论选择哪种方案，都应区分 “主应用下发的只读状态” 与 “子应用本地状态”，保持单向数据流（主 -> 子：同步消费；子 -> 主：通过 setGlobalState 通知），避免双向直接修改导致不可预测的 bug。