目录 (Outline)
- 一、 微前端的「隔离」与「连接」：为什么状态同步这么难？
- 二、 历史方案：从 window 变量到单向数据流
- 三、 现代微前端框架的「官方方案」：以 qiankun 为例
- 四、 实战 1：基于 CustomEvent 的轻量级同步（跨框架友好）
- 五、 实战 2：Zustand 的跨应用中间件方案
- 六、 进阶：如何处理状态冲突与循环更新？
- 七、 总结：微前端状态管理的黄金法则
一、 微前端的「隔离」与「连接」：为什么状态同步这么难？
1. 隔离的初衷
微前端的核心目标是让子应用具备自治权：独立的依赖、独立的开发环境、独立的部署。因此，子应用的状态默认应该是私有的。
2. 连接的需求
然而，在复杂的业务中，子应用之间往往需要共享一些全局信息：
- 用户信息（Avatar、Token、Roles）。
- 购物车状态。
- 主题配置（Theme、Language）。
如何在不破坏子应用隔离性的前提下，实现状态的高效同步，是微前端架构的关键难题。
二、 历史方案：从 window 变量到单向数据流
1. 「混沌时代」：直接挂载 window
最原始的方式是把所有东西都塞进 window.globalState。
- 缺点：命名冲突风险极大；状态不可追踪；缺乏响应式，修改后其他子应用不知道。
2. 「事件时代」：Event Bus
通过发布订阅模式传递消息。
- 缺点：事件分散，难以调试；无法保证状态的一致性（容易出现旧数据覆盖新数据）。
三、 现代微前端框架的「官方方案」：以 qiankun 为例
主流框架如 qiankun 提供了一个内置的 initGlobalState API。
核心流程
- 主应用初始化：
const actions = initGlobalState(initialState)。 - 子应用注入：主应用通过
props将onGlobalStateChange和setGlobalState传给子应用。 - 数据双向流：任何一方调用
setGlobalState，其他订阅者都会收到回调。
这种方案简单有效，但它是侵入式的，需要子应用修改入口文件。
四、 实战 1：基于 CustomEvent 的轻量级同步（跨框架友好）
如果你希望实现一个跨框架（例如主应用是 React，子应用是 Vue）的同步方案，CustomEvent 是最佳选择。
实现思路：全局状态分发器
// shared-store.js
class GlobalDispatcher {
static dispatch(type, payload) {
const event = new CustomEvent('MICRO_STATE_SYNC', {
detail: { type, payload }
});
window.dispatchEvent(event);
}
static subscribe(callback) {
window.addEventListener('MICRO_STATE_SYNC', (e) => callback(e.detail));
}
}
在子应用中使用
// React 子应用
useEffect(() => {
GlobalDispatcher.subscribe(({ type, payload }) => {
if (type === 'USER_UPDATED') {
setUser(payload);
}
});
}, []);
五、 实战 2：Zustand 的跨应用中间件方案
Zustand 因其轻量和函数式 API，在微前端场景下极具优势。我们可以编写一个简单的中间件，让子应用的状态变更自动同步到全局。
实现同步中间件
const syncMiddleware = (config) => (set, get, api) => config(
(args) => {
set(args);
// 同步到全局
window.dispatchEvent(new CustomEvent('SYNC_TO_HOST', { detail: get() }));
},
get,
api
);
// 定义子应用 Store
export const useStore = create(syncMiddleware((set) => ({
count: 0,
inc: () => set((state) => ({ count: state.count + 1 })),
})));
六、 进阶：如何处理状态冲突与循环更新？
在多方同步时，极易出现 A 更新导致 B 更新，B 又反过来触发 A 的死循环。
解决方案
- 状态指纹 (Hash Check)：在同步前计算状态的哈希值，如果哈希值未改变，则不触发更新。
- 来源标记 (Origin Tagging)：在 Event 的
detail中增加from: 'app-a'标记，订阅者只处理来自其他来源的更新。 - 单向同步原则：尽量让状态同步由「主应用」下发，子应用通过「动作 (Action)」请求更新，而不是直接修改。
七、 总结：微前端状态管理的黄金法则
- 按需共享：能不共享的就不共享，尽量保持子应用的原子性。
- 响应式优先：确保同步是实时的，避免数据延迟导致的 UI 不一致。
- 低耦合：尽量使用浏览器原生 API（如
CustomEvent）或轻量级库，避免子应用强绑定主应用的架构。
