微前端通信方案深度解析

一句话概括

微前端通信是跨子应用交换数据的设计模式集合，从最松耦合的 URL 参数、到中等耦合的事件总线、再到紧耦合的全局共享状态，每种方案都有其适用场景与代价。一个成熟的微前端架构通常同时存在 3-4 种通信方式，关键是按”数据是短暂还是持久、传递是单向还是双向、能接受多高的耦合度”三个维度做权衡。

核心知识点

1. URL 参数：最松耦合

URL 传参零依赖、刷新不丢、可分享，但只能传字符串、有长度限制：

// 基座切换子应用时通过 URL 传参
function navigateToProduct(productId) {
  const url = new URL(window.location.href);
  url.searchParams.set('productId', productId);
  // 用 history 更新，不刷新页面，子应用通过路由监听变化
  window.history.pushState({}, '', url);
}
// 子应用里读取
const productId = new URLSearchParams(window.location.search).get('productId');
// 适合：进入子应用的初始参数、可分享/可刷新的状态

2. 事件总线：发布订阅

事件总线让子应用零依赖通信，适合”广播通知”类的一次性事件：

// 极简事件总线
class EventBus {
  constructor() { this.events = new Map(); }
  on(type, handler) {
    if (!this.events.has(type)) this.events.set(type, []);
    this.events.get(type).push(handler);
  }
  emit(type, payload) {
    (this.events.get(type) || []).forEach(h => h(payload));
  }
  off(type, handler) {
    const list = this.events.get(type) || [];
    this.events.set(type, list.filter(h => h !== handler));
  }
}

const bus = new EventBus();
// 购物车子应用：商品加入购物车后广播
bus.emit('cart:add', { productId: 'p_1' });
// 顶栏 badge 子应用：订阅并更新角标
bus.on('cart:add', ({ productId }) => updateBadge(productId));

3. 全局状态：qiankun 的 initGlobalState

需要”持久共享、多处同步”的数据（如用户信息），用全局状态更合适。qiankun 内置了基于发布订阅的全局状态：

import { initGlobalState } from 'qiankun';

const actions = initGlobalState({ user: null, cart: 0 });

// 基座侧：监听 + 修改
actions.onGlobalStateChange((state, prev) => {
  console.log('变化:', state.user);
});
actions.setGlobalState({ user: { name: '张三' } });

// 子应用侧：mount 时拿到 props 里的通信方法
export async function mount(props) {
  props.onGlobalStateChange((state) => console.log('子应用:', state.user));
  props.setGlobalState({ cart: 3 }); // 子应用反向更新全局状态
}

4. 自定义事件 / CustomEvent

原生 CustomEvent 是零依赖的通信手段，适合浏览器原生能力够用的场景：

// 子应用 A 派发自定义事件
window.dispatchEvent(new CustomEvent('user:login', { detail: { userId: 'u_1' } }));

// 子应用 B 监听
window.addEventListener('user:login', (e) => {
  console.log('收到登录事件:', e.detail.userId);
});

其实你每天都在用

1. 分享一个商品链接给朋友：URL 里那串 ?productId=xxx&from=share，就是微前端里 URL 传参通信——打开链接的人直接看到对应商品，状态随链接传递。
2. 登录后所有页面同时显示头像和昵称：顶部导航、侧边栏、个人中心同时更新，就是全局状态广播（initGlobalState）的日常效果。
3. 加入购物车后角标数字 +1：商品页派发”加入购物车”事件，购物车角标监听并更新——这是最典型的事件总线通信。
4. 浏览器里的 localStorage 跨标签页同步：A 标签页修改了设置，B 标签页通过 storage 事件感知变化，这是微前端跨应用通信的浏览器原生版。
5. 微前端基座的”壳”和”内容”分工：基座负责登录态、导航，子应用负责具体业务，它们之间的数据交换就是微前端通信要解决的问题。

常见误解（FAQ）

❌ 误区一：通信方案越”高级”越好，都用全局状态就对了。 错误。全局状态是紧耦合——所有子应用共享同一份状态，改一处可能影响全局，且破坏了”独立部署”的初衷。能 URL 传参解决的就不用事件总线，能事件总线解决的就不用全局状态。松耦合优先。

❌ 误区二：事件总线发出去的事件一定有子应用接收。 错误。事件总线是”发布即忘”——如果订阅方还没挂载（子应用未激活），事件就丢了。对于”登录态”这类需要持久化的数据，应该用全局状态（订阅时立即同步当前值），而不是事件总线（只通知未来变化）。

❌ 误区三：URL 传参可以传复杂对象。 错误。URL 只能传字符串，复杂对象需要 JSON.stringify + 编码，且受 URL 长度限制（浏览器约 2000 字符左右），还容易泄露敏感信息（URL 会出现在日志、历史记录、分享里）。敏感数据绝不该走 URL。

❌ 误区四：CustomEvent 和事件总线是同一回事。 错误。CustomEvent 是浏览器原生 API，依赖 window 全局（跨子应用天然隔离不了，还容易全局污染）；事件总线是应用内的发布订阅实现，可以控制作用域和生命周期。两者机制相似，但作用域和可控性不同。

一句话总结

微前端通信没有银弹，只有”匹配度”——短暂、可分享的数据走 URL，一次性通知走事件总线，持久共享的状态走全局状态，核心原则是：能用松耦合解决的，绝不上紧耦合。