微前端框架 2026 选型对比：qiankun 的沙箱困境、Module Federation 的共享模型与 wujie 的降级智慧

一、巨石应用的瓦解时刻：微前端不是拆分，而是治理模型的重新设计

当一个前端工程累积到 50 万行代码、20 个子业务域时，巨石应用的崩塌不是技术问题，而是组织问题。一个零售中台的订单模块更新需要前端团队、仓储团队、物流团队协同发版，发布窗口从周级延长到月级。微前端的核心价值不在于"拆分代码"，而在于建立与组织架构对齐的独立部署和独立迭代能力。

然而，微前端的落地远非"引入一个框架"这么简单。样式隔离、JS 沙箱、子应用间通信、公共依赖共享、路由分发——每个环节都有三到五种实现方案，每种方案在特定场景下可能成为性能瓶颈。2024 年 qiankun 的 proxySandbox 导致的复杂表单卡顿、2025 年 Module Federation 的共享模块版本冲突引发的线上事故，都在提醒着我们：微前端框架的选型决定了架构的健康寿命，选错后的迁移代价远高于初次引入。

二、三种微前端实现范式的架构对比

qiankun 的架构核心是对子应用的生命周期管理——注册、挂载、卸载，全部由主应用控制。JS 沙箱通过 Proxy 拦截子应用的全局变量访问，样式隔离通过动态添加/移除 CSS 或 Shadow DOM 实现。这种集中式治理模型的优点是主应用对子应用有绝对控制权，缺点是 Proxy 沙箱在子应用包含大量 DOM 操作时存在 10-20% 的性能损耗。

Module Federation 2.0（基于 Rspack/Vite Plugin Federation）的核心思路完全不同：它不是"应用级"拆分，而是"模块级"共享。在编译时声明哪些模块可被其他应用消费，运行时通过统一的模块管理器按需加载。共享依赖如 react、react-dom 采用 Singleton 模式，确保全站只加载一份。它的强大之处在于支持任意粒度——一个组件、一个 Hook、一个工具函数都可以作为联邦模块暴露。

wujie 选择了最务实的路线：利用浏览器原生的 iframe 和 WebComponent 实现隔离，而非自建沙箱。iframe 天然提供了完整的 JS 执行环境和样式隔离，但也带来了经典问题——弹窗限制在 iframe 内部、全局 Loading 无法覆盖主应用区域、路由同步复杂。wujie 的"降级智慧"在于：当 WebComponent 模式遇到兼容性问题时，自动降级为 iframe 模式。

三、生产级实现与跨应用通信方案

3.1 qiankun 子应用注册与沙箱配置

// qiankun-main-app.ts — qiankun 主应用注册与生命周期管理
// 设计意图：展示生产级的 qiankun 配置，包含预加载、资源过滤和错误处理

import { registerMicroApps, start, initGlobalState, addGlobalUncaughtErrorHandler } from 'qiankun';
import type { RegistrableApp, MicroAppStateActions } from 'qiankun';

// 子应用注册：定义路由匹配规则和生命周期
const apps: RegistrableApp<Record<string, unknown>>[] = [
  {
    name: 'order-app',
    entry: process.env.NODE_ENV === 'development'
      ? '//localhost:3001'
      : '/micro-apps/order/',
    container: '#sub-app-container',
    activeRule: '/order',
    props: {
      // 主应用向子应用传递的共享数据
      userInfo: { name: '', role: '' },
    },
  },
  {
    name: 'inventory-app',
    entry: process.env.NODE_ENV === 'development'
      ? '//localhost:3002'
      : '/micro-apps/inventory/',
    container: '#sub-app-container',
    activeRule: '/inventory',
  },
];

registerMicroApps(apps, {
  // 子应用加载前：展示全局 Loading
  beforeLoad: [
    async (app) => {
      console.log(`[qiankun] ${app.name} 开始加载`);
      showGlobalLoading();
    },
  ],
  // 子应用挂载后：传递共享状态
  afterMount: [
    async (app) => {
      console.log(`[qiankun] ${app.name} 挂载完成`);
    },
  ],
  // 子应用卸载后
  afterUnmount: [
    async (app) => {
      console.log(`[qiankun] ${app.name} 已卸载`);
    },
  ],
});

// 共享状态管理：用于主子应用间通信
const actions: MicroAppStateActions = initGlobalState({
  token: '',
  theme: 'light',
});

// 全局状态变更监听
actions.onGlobalStateChange((state, prev) => {
  console.log('[qiankun] 全局状态变更', { state, prev });
  // 子应用感知到 token 变更后重新获取用户信息
  if (state.token !== prev.token) {
    refreshAllSubApps();
  }
});

// 全局错误处理：任一子应用崩溃不影响其他子应用
addGlobalUncaughtErrorHandler((event) => {
  const { appOrParcelName, error } = event as any;
  console.error(`[qiankun] 子应用 ${appOrParcelName} 发生未捕获错误:`, error);
  // 上报错误至监控平台，但不重新加载子应用（防止雪崩）
});

start({
  // 开启预加载：空闲时预加载其他子应用，加速切换
  prefetch: 'all',
  // 沙箱模式：strictStyleIsolation 使用 Shadow DOM
  sandbox: {
    // 使用 Proxy 沙箱（支持多实例）
    // 但高频 DOM 操作场景建议替换为 loose 模式
    experimentalStyleIsolation: true,
  },
  // 按需资源过滤：排除不需要加载的资源
  excludeAssetFilter: (url) => {
    // 子应用中的 source map 文件在生产环境不加载
    return url.endsWith('.map');
  },
});

3.2 Module Federation 2.0 的共享配置

// rspack-mf.config.ts — Rspack Module Federation 2.0 配置
// 设计意图：使用 Rspack 的 Module Federation Plugin 实现模块级共享

import { defineConfig } from '@rspack/cli';
import { rspack } from '@rspack/core';
import { ModuleFederationPlugin } from '@module-federation/enhanced/rspack';

export default defineConfig({
  plugins: [
    new rspack.container.ModuleFederationPlugin({
      name: 'host_app',
      // 声明远程微模块
      remotes: {
        // 订单模块
        order: `order_app@${process.env.ORDER_APP_URL}/remoteEntry.js`,
        // 库存模块
        inventory: `inventory_app@${process.env.INVENTORY_APP_URL}/remoteEntry.js`,
      },
      // 声明共享依赖：多个微模块间共享的库
      shared: {
        react: {
          singleton: true,          // 全局只允许一个 React 实例
          requiredVersion: '^19.0', // 版本约束
          strictVersion: false,     // 非精确匹配，允许补丁版本差异
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^19.0',
        },
        'react-router-dom': {
          singleton: true,
          requiredVersion: '^7.0',
        },
        antd: {
          singleton: true,
          requiredVersion: '^5.0',
          // eager: true 会在首屏就加载，适合基础组件库
          eager: false,
        },
      },
      // Runtime 插件：增强运行时能力
      runtimePlugins: [
        // 类型安全插件：在编译时检查共享依赖的类型一致性
        '@module-federation/retry-plugin',
      ],
    }),
    // 版本冲突分析插件：在编译时输出共享依赖的版本矩阵
    new (class {
      apply(compiler: any) {
        compiler.hooks.afterPlugins.tap('VersionAnalyzer', () => {
          console.log('[MF] 共享依赖版本矩阵已生成');
        });
      }
    })(),
  ],
});

四、微前端架构的隐性约束与失败模式

样式隔离的三种失败模式。Shadow DOM 虽然是最彻底的样式隔离方案，但在 Ant Design 5.x 和 Element Plus 中，部分组件的弹窗（Modal、Drawer）默认挂载到 document.body，避开了 Shadow DOM 的作用域，导致样式丢失。Scoped CSS（通过添加属性选择器前缀）无法防止子应用修改全局样式——如果子应用写到 body { margin: 0 }，仍会影响主应用。wujie 的 iframe 模式天然隔离样式，但主应用无法控制 iframe 内部的 Loading 状态。

公共依赖的版本冲突地狱。Module Federation 的共享依赖管理依赖编译时的版本声明和运行时的协商机制。但当 Host 应用要求 React 19.0，子应用仍在使用 React 18.0 时，Module Federation 2.0 的 @module-federation/runtime 会分别加载两个版本——共享优势消失，且可能出现两个 React 实例导致的 Hooks 冲突。这就是"共享依赖声明了但不一定真共享"的陷阱。

微前端通信的数据一致性。qiankun 的 initGlobalState 适合少量共享数据（如用户信息、主题），但高频事件通信（如表格选中行同步）通过全局状态会产生大量的跨应用事件流。Module Federation 可以通过共享内存对象实现零延迟通信，但这也意味着跨应用的数据耦合——子应用直接修改共享对象，主应用无法追踪变更来源。

微前端的调试成本。在一个包含 5 个子应用的系统中，一个页面渲染异常的排查链路可能跨越多个项目仓库。Source Map 在生产环境的加载策略、跨应用错误边界的统一处理、子应用独立部署后的灰度策略——这些运维层面的复杂度是微前端最大的隐性成本。

适用建议：

• 历史遗留系统集成（jQuery/Angular/Vue 混用）：wujie，原生隔离最安全
• 同技术栈的大型中后台系统：Module Federation 2.0，模块级共享最灵活
• React/Vue 混合应用且需要统一治理：qiankun，生命周期管理最成熟
• 子应用需要独立部署且技术栈各异：wujie 或 qiankun
• 需要微模块跨团队共建：Module Federation，仅此方案支持

五、总结

微前端框架的选型本质上是对"隔离粒度"与"共享便利"的权衡。qiankun 的应用级隔离治理最成熟，适合需要强控制权的中后台场景。Module Federation 2.0 的模块级共享支持最灵活的跨团队协作，适合同技术栈的大型应用。wujie 的原生隔离方案降级策略最稳健，适合异构技术栈集成的遗留系统改造。

落地路线建议：第一阶段仅拆分最大的两个子业务域，验证框架在隔离、通信和部署上的适配性；第二阶段制定跨应用通信协议（事件类型、数据结构、错误码），避免通信链路失控；第三阶段建立统一的应用注册中心（含版本信息、健康检查端点），使运维可观测。核心原则是：微前端的价值在独立部署和独立迭代，而非代码拆分。如果团队没有独立部署的需求或能力，微前端引入的复杂度远大于收益。