本周大前端要闻

• Compose Multiplatform v1.11.10-alpha01：进一步完善跨平台 UI 状态同步能力，ViewModel 共享机制改进

• KotlinConf'26 演讲阵容公布：多场 Session 聚焦 Kotlin 多平台架构与状态管理，值得关注

• Retrofit 3.0.0 正式发布：全面迁移 OkHttp 4.12 Kotlin 版，影响 Android 端异步状态层设计

• Android Studio Panda 3 稳定版发布：Gemma 4 AICore 本地模型开发预览，AI 辅助架构决策成可能

• Kotlin 2.3.20 发布：K2 编译器稳定，多平台构建配置大幅简化，跨端状态共享门槛降低

大前端架构

微前端落地的第一个坑，往往不是路由，不是样式隔离，而是状态。

你可以把微前端的状态共享问题想象成一栋合租公寓：每个租客（子应用）都想自己管钥匙，但门禁系统（全局权限）必须所有人共用，钥匙到底放在哪里、谁来备份，是每次搬来新租客都要重新协商的问题。你不可能让每个人都带一把门禁主机回自己房间，但也不能强迫大家每次开门都绕到物业前台。

当你把一个大型 SPA 拆分成五个独立部署的子应用，之前塞在 Redux store 里的全局状态——用户信息、购物车、权限、主题——突然成了一个需要多方协商的共识问题。每个子应用都想拥有自己的状态层，但又免不了要互相感知。

这篇文章讲微前端架构下状态管理的真实困境，以及用 Module Federation + 事件总线 + 共享 Store 三种方案组合应对的实战经验。不讲概念，讲决策。

① 先把问题讲清楚

微前端状态管理的核心矛盾是：独立性 vs 一致性。

每个子应用（微应用）应该是自治的——独立开发、独立部署、独立测试。自治意味着它应该有自己的状态层，不依赖其他子应用的运行时。

但现实是，你的"购物车"微应用需要知道"用户"微应用里的登录态；"商品详情"需要感知"权限"模块的配置；主框架需要协调子应用之间的 loading 状态。

这些跨应用的状态共享需求是客观存在的，不是设计失误。问题在于：怎么共享才不破坏隔离？

我见过三种常见的错误做法：

错误一：全局 window 对象共享

window.__globalStore、window.__userInfo——简单，但污染全局命名空间，无法追踪来源，测试噩梦。

错误二：主应用向子应用注入 props/context

主框架把 store 当 props 传进子应用——形成强依赖，子应用无法独立运行，违背微前端的核心价值。

错误三：每个子应用都维护同一份状态的副本

购物车微应用和订单微应用各自维护用户信息——同步问题是噩梦，race condition 必然出现。

所以合理的架构思路是什么？

② 状态分层：先把状态按归属划分

在选方案之前，先做状态分层——这是一切的前提。并非所有状态都需要跨应用共享。

状态归属三层模型：

 全局共享层

用户身份/权限、全局主题/语言、路由元信息、全局弹窗/通知队列

→ 由主框架或专用 Store 微应用负责，单一数据源

 跨应用协作层

购物车状态、跨模块业务流程（下单 → 支付 → 物流）

→ 通过事件总线或共享 Store 片段协调，需要明确的所有权归属

 局部私有层

表单状态、UI 交互态（展开/折叠）、分页参数、列表缓存

→ 子应用内部自管，Zustand/Redux Toolkit 均可，外部无需感知

这个分层做完，你会发现：真正需要跨应用的状态其实很少，大多数都是局部的。过度设计的"全局 store"是微前端架构腐化的主要原因之一。

③ Module Federation：把 Store 当模块共享

Webpack 5 的 Module Federation（MF）通常被当成"代码共享"工具，但它对状态管理有一个极为关键的能力：共享单例（singleton）。

核心思路是：把 Zustand/Redux store 实例封装为一个独立的共享模块，通过 MF 的 singleton: true 配置，确保所有微应用共用同一个 store 实例，而不是各自实例化一份。

3.1 共享 Store 微应用配置

先创建一个专门的 store-provider 微应用，只负责提供全局状态。关键点是用 singleton: true 告诉 MF "这个模块全局只允许有一个实例"：

// store-provider/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'storeProvider',
      filename: 'remoteEntry.js',
      exposes: {
        // 暴露用户 Store
        './userStore': './src/stores/userStore',
        './cartStore': './src/stores/cartStore',
        './eventBus': './src/eventBus',
      },
      shared: {
        // 关键：zustand 必须 singleton，否则各子应用状态不共享
        zustand: { singleton: true, requiredVersion: '^4.5.0' },
        react: { singleton: true, requiredVersion: '^18.3.0' },
        'react-dom': { singleton: true, requiredVersion: '^18.3.0' },
      },
    }),
  ],
};

3.2 子应用消费共享 Store

消费方直接 import 远程模块，得到的是同一个 store 实例——对子应用代码来说，和用本地 store 没有区别：

// cart-app/webpack.config.js
new ModuleFederationPlugin({
  name: 'cartApp',
  remotes: {
    // 指向 store-provider 的 remoteEntry
    storeProvider: 'storeProvider@https://cdn.example.com/store/remoteEntry.js',
  },
  shared: {
    zustand: { singleton: true },  // 消费方也必须声明 singleton
    react: { singleton: true },
  },
})

// cart-app/src/CartPage.tsx
// 直接 import 共享 store——得到的是同一个实例
import { useCartStore } from 'storeProvider/cartStore';

export function CartPage() {
  const { items, addItem, removeItem } = useCartStore();
  return (
    
      {items.map(item => (
        
      ))}
    
  );
}

这种方式的核心优势：子应用在 独立运行时可以 fallback 到本地 store，在集成环境自动使用共享 store——只需在 store 初始化时做条件判断。下面这段展示了如何在 store 本身不感知"是否在微前端环境"的前提下，做到透明切换：

// cart-app/src/stores/cartStore.ts
// 独立运行时用本地 store，集成时被 MF singleton 覆盖
import { create } from 'zustand';

interface CartState {
  items: CartItem[];
  addItem: (item: CartItem) => void;
  removeItem: (id: string) => void;
}

export const useCartStore = create()((set) => ({
  items: [],
  addItem: (item) => set((s) => ({ items: [...s.items, item] })),
  removeItem: (id) => set((s) => ({ items: s.items.filter(i => i.id !== id) })),
}));

④ 事件总线：解耦跨应用通信

并非所有跨应用交互都适合共享 store。有些场景更适合「发布-订阅」模型：子应用 A 完成了某个操作，通知子应用 B 做出响应，但 A 和 B 互相不知道对方的存在。

典型场景：用户在"商品详情"微应用点击"加入购物车"，触发"购物车"微应用的角标更新、"推荐"微应用的埋点上报。这是一对多的通知关系，强制绑定 store 反而引入不必要的耦合。

4.1 类型安全的事件总线实现

// shared/eventBus.ts（通过 MF 暴露给所有子应用）
type EventMap = {
  'cart:item-added': { productId: string; quantity: number };
  'user:logged-in': { userId: string; token: string };
  'user:logged-out': void;
  'order:created': { orderId: string; totalAmount: number };
  'global:theme-changed': { theme: 'light' | 'dark' };
};

type Handler = (payload: T) => void;

class TypedEventBus {
  private handlers = new Map>>();

  on(
    event: K,
    handler: Handler
  ): () => void {
    if (!this.handlers.has(event as string)) {
      this.handlers.set(event as string, new Set());
    }
    this.handlers.get(event as string)!.add(handler);
    // 返回取消订阅函数，避免内存泄漏
    return () => this.handlers.get(event as string)?.delete(handler);
  }

  emit(event: K, payload: EventMap[K]): void {
    this.handlers.get(event as string)?.forEach(h => h(payload));
  }
}

// 单例导出，通过 MF singleton 确保全局唯一
export const eventBus = new TypedEventBus();

4.2 在 React 子应用中使用事件总线

// product-app/src/ProductDetail.tsx
import { eventBus } from 'storeProvider/eventBus';

export function ProductDetail({ product }: { product: Product }) {
  const handleAddToCart = () => {
    // 发布事件——不依赖购物车应用是否存在
    eventBus.emit('cart:item-added', {
      productId: product.id,
      quantity: 1,
    });
  };
  return 加入购物车;
}

// cart-app/src/CartBadge.tsx
import { useEffect, useState } from 'react';
import { eventBus } from 'storeProvider/eventBus';

export function CartBadge() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    // 订阅事件，返回值是取消订阅函数
    const unsubscribe = eventBus.on('cart:item-added', () => {
      setCount(c => c + 1);
    });
    return unsubscribe; // cleanup：组件卸载时自动取消订阅
  }, []);

  return  {count};
}

注意事件取消订阅的必要性——微前端环境下子应用频繁挂载/卸载，内存泄漏问题比普通 SPA 更严重。用返回值 cleanup 函数是最干净的写法。

⑤ 隔离的另一面：避免状态污染

共享状态解决了"无法沟通"的问题，但也引入了"沟通太多"的风险。

最常见的状态污染场景：子应用 A 在路由离开时没有清理 store，下次子应用 B 挂载时拿到了脏数据。或者子应用 A 的定时任务在后台继续修改共享 store，导致 UI 出现幽灵更新。

5.1 子应用生命周期钩子清理状态

// 以 qiankun/single-spa 为例
// product-app/src/main.ts
import { useProductStore } from './stores/productStore';
import { eventBus } from 'storeProvider/eventBus';

let eventUnsubscribers: Array void> = [];

// 子应用挂载时注册监听
export async function mount(props: any) {
  const unsub1 = eventBus.on('user:logged-out', () => {
    useProductStore.getState().reset(); // 登出时清空商品缓存
  });
  eventUnsubscribers.push(unsub1);
  renderApp(props);
}

// 子应用卸载时清理
export async function unmount() {
  // 取消所有事件订阅
  eventUnsubscribers.forEach(fn => fn());
  eventUnsubscribers = [];
  
  // 重置私有 store
  useProductStore.getState().reset();
  
  // 销毁 React 根
  root.unmount();
}

5.2 Zustand store 的 reset 设计

在 store 设计时，提前预留 reset 接口是微前端架构的最佳实践：

const initialState = {
  products: [] as Product[],
  selectedId: null as string | null,
  loading: false,
};

export const useProductStore = create void }
>()((set) => ({
  ...initialState,
  reset: () => set(initialState), // 一键重置到初始状态
}));

⑥ 方案选型总结

三种模式适合不同场景，不是非此即彼的关系：

方案	适用状态类型	隔离性	调试难度
MF 共享 Store	全局身份/权限/主题	低（共享实例）	低（Redux DevTools 支持）
事件总线	跨应用业务通知	高（松耦合）	中（需日志追踪）
子应用私有 Store	UI 交互/局部业务	最高（完全隔离）	最低（单应用调试）

实战建议：大多数状态放私有，少数全局通过 MF singleton 共享，跨应用交互优先用事件总线。出现"我需要在子应用里访问另一个子应用的内部状态"时，往往是架构设计出了问题——需要重新审视边界，而不是硬加一个共享通道。

⑦ 一个踩坑笔记

最后分享一个在生产中遇到的真实问题。

我们用 Zustand + MF singleton 共享用户 store，初期一切正常。某天上线后，部分用户反馈"登出后仍然能看到上一个用户的数据"。

排查了很久，最后发现问题出在：子应用 B 在本地开发时忘记声明 zustand: { singleton: true }，导致测试环境没问题（因为都是本地单进程），但生产环境子应用 B 实例化了自己的 zustand，共享 store 的更新无法传递到子应用 B。

MF singleton 是"两端约定"

提供方声明 singleton 不够——每个消费方也必须声明 singleton，否则会各自维护一个实例。建议把 shared 配置抽成团队共享的 npm 包统一维护，避免各微应用各自配置漂移。

这也是微前端架构的一个普遍特征：问题往往不出在技术实现上，而出在跨团队约定的遵守上。架构师的核心工作之一，是把这些约定变成机制（lint 规则、CI 检查、共享配置包），而不是靠口头协议。

小结

微前端的状态管理不需要一个"终极方案"，需要的是清晰的分层和边界意识：

• 先做状态分层，确认哪些状态真的需要跨应用共享

• 全局状态用 MF singleton 共享，但消费方必须对等声明

• 跨应用通知用类型安全的事件总线，松耦合优先

• 子应用内部状态保持完全隔离，卸载时务必清理

• 把约定变成工具和机制，不要依赖人工记忆

状态管理本质上是一个关于"数据所有权"的问题。在微前端里，把这个问题想清楚，比选什么技术栈更重要。

如果你在微前端落地中遇到过状态管理的坑，欢迎留言交流。下期我们聊聊 Signal 机制在 Angular/Vue/Solid 中的横向对比——那是另一种完全不同的状态管理哲学。