前端微前端架构深度对比：qiankun vs MicroApp vs Module Federation

一、微前端核心价值与适用场景

1.1 什么是微前端

微前端（Micro Frontends）是一种架构风格，它将前端应用分解为多个小型、独立交付的前端应用，这些应用可以独立开发、独立部署，最终组合成一个完整的用户体验。这个概念借鉴了后端微服务架构的思想，旨在解决单体前端应用随着业务增长而变得难以维护的问题。

在传统的单体前端架构中，随着团队规模扩大和业务复杂度提升，代码库会迅速膨胀，构建时间变长，技术栈升级困难，团队之间的协作成本急剧上升。微前端通过将应用拆分为多个自治的子应用，使不同团队可以使用不同的技术栈，独立迭代和部署，从而实现真正的业务解耦。

// 传统单体架构 vs 微前端架构对比

// ============ 单体架构 ============
// 所有功能打包在一个应用中
app/
├── src/
│   ├── user-center/   // 用户中心模块
│   ├── order-system/  // 订单系统模块
│   ├── product-show/  // 商品展示模块
│   └── payment/       // 支付模块
├── package.json
└── webpack.config.js  // 单一构建配置

// 问题：
// 1. 构建时间长（全量构建）
// 2. 技术栈绑定（无法局部升级）
// 3. 团队耦合（代码冲突频繁）
// 4. 发布风险高（一个小改动需全量发布）

// ============ 微前端架构 ============
// 主应用（容器）
main-app/
├── src/
│   └── router.js      // 子应用注册与路由
└── package.json

// 子应用1：用户中心（Vue 3）
user-center/
├── src/
├── package.json
└── vue.config.js

// 子应用2：订单系统（React 18）
order-system/
├── src/
├── package.json
└── webpack.config.js

// 子应用3：商品展示（Vue 2）
product-show/
├── src/
├── package.json
└── vue.config.js

// 优势：
// 1. 独立构建、独立部署
// 2. 技术栈无关（各子应用可自由选择）
// 3. 团队自治（减少协作冲突）
// 4. 增量升级（逐步迁移旧系统）

1.2 微前端的核心价值

微前端架构的核心价值在于解决大型前端应用开发中的"规模问题"。当应用代码超过10万行，开发团队超过20人时，单体架构的维护成本会呈指数级增长。微前端通过以下方式创造价值：

首先是技术栈无关性。不同子应用可以使用不同的前端框架（React、Vue、Angular等），这使得团队可以根据业务特点选择最适合的技术栈，同时也让老项目的渐进式重构成为可能。其次是独立部署能力，每个子应用都有独立的构建流水线和部署流程，某个功能的更新不需要重新部署整个应用。

// 微前端核心价值维度分析

维度              | 单体架构    | 微前端架构
------------------|------------|------------
构建速度          | 随代码量线性增长 | 子应用并行构建，速度恒定
技术栈升级        | 全量升级，风险高 | 子应用独立升级，风险可控
团队协作          | 共享代码库，易冲突 | 独立仓库，边界清晰
发布频率          | 统一发布，周期长 | 独立发布，按需上线
故障隔离          | 一处报错，整体崩溃 | 子应用隔离，互不影响
性能优化          | 全局优化，难度大 | 局部优化，精准施策

// 适用场景判断
const shouldUseMicroFrontend = (team, codebase, business) => {
  const score = 0;
  
  // 团队规模（>15人建议微前端）
  if (team.size > 15) score += 3;
  else if (team.size > 8) score += 1;
  
  // 代码规模（>10万行建议微前端）
  if (codebase.lines > 100000) score += 3;
  else if (codebase.lines > 50000) score += 1;
  
  // 业务复杂度（多业务线建议微前端）
  if (business.lines > 3) score += 2;
  
  // 技术栈异构需求
  if (business.needHeterogeneousTech) score += 3;
  
  return score >= 5; // 总分>=5分建议使用微前端
};

// 实际案例：某电商平台
// 团队：30+ 开发人员，分5个业务线
// 代码：15万+ 行，Vue 2 老项目需迁移至 Vue 3
// 决策：采用微前端，逐步迁移各业务线
// 结果：6个月内完成核心业务迁移，零停机

1.3 微前端适用场景分析

并非所有项目都适合采用微前端架构。微前端引入的复杂度需要通过业务价值来抵消。以下场景特别适合采用微前端：

大型企业级应用是最典型的适用场景，如企业SaaS平台、电商中台系统、金融核心业务系统等。这些系统通常具有以下特征：多业务线并行开发、用户角色复杂、功能模块众多、技术栈历史包袱重。此外，渐进式重构项目也非常适合微前端，特别是需要将老旧的jQuery或AngularJS项目逐步迁移到现代框架时。

// 微前端适用场景决策树

/**
 * 是否应该使用微前端？
 * 
 * 场景1：大型企业门户
 *   - 特征：多部门、多子系统、统一入口
 *   - 案例：阿里云控制台、腾讯云控制台
 *   - 建议：✅ 强烈推荐
 * 
 * 场景2：遗留系统迁移
 *   - 特征：老技术栈、不敢动、新功能继续堆积
 *   - 案例：从 AngularJS 迁移到 Vue 3
 *   - 建议：✅ 推荐（Module Federation 方案）
 * 
 * 场景3：多团队协作
 *   - 特征：>3个团队、独立迭代、独立发布
 *   - 案例：电商平台（商品、订单、支付独立团队）
 *   - 建议：✅ 推荐（qiankun 方案成熟）
 * 
 * 场景4：简单SaaS应用
 *   - 特征：<5万行代码、<10人团队、单一业务
 *   - 建议：❌ 不推荐（过度设计）
 * 
 * 场景5：初创项目MVP
 *   - 特征：快速验证、需求多变、资源有限
 *   - 建议：❌ 不推荐（先单体，后拆分）
 */

// 不适合微前端的信号
const redFlags = [
  '团队规模 < 8人',           // 沟通成本低于拆分收益
  '代码量 < 5万行',           // 单体维护成本可控
  '单一业务线',               // 没有拆分的业务基础
  '追求极致首屏性能',         // 微前端有额外加载开销
  '团队缺乏架构治理能力',     // 微前端需要较强的工程化能力
];

二、qiankun（基于Single-SPA）架构解析

2.1 qiankun 架构概览

qiankun 是蚂蚁集团开源的微前端框架，基于 Single-SPA 封装，提供了更加开箱即用的微前端解决方案。它通过 JavaScript 入口文件来加载子应用，利用 import-html-entry 解析子应用的 HTML 入口，提取 JS 和 CSS 资源进行加载和执行。qiankun 的核心优势在于其完善的样式隔离、JS 沙箱机制和预加载能力。

qiankun 的架构设计遵循"主从模式"：一个主应用（基座）负责注册和调度子应用，子应用需要暴露特定的生命周期钩子（bootstrap、mount、unmount）。当路由匹配到子应用时，主应用会动态加载子应用的资源，并在适当的时机调用其生命周期函数，实现子应用的挂载和卸载。

// qiankun 主应用配置示例

import { registerMicroApps, start, initGlobalState } from 'qiankun';

// 1. 注册子应用
registerMicroApps([
  {
    name: 'user-center',           // 子应用名称
    entry: '//localhost:8081',     // 子应用入口（支持HTML和JS入口）
    container: '#subapp-container', // 子应用挂载容器
    activeRule: '/user',           // 激活路由规则
    props: {                       // 传递给子应用的全局属性
      token: localStorage.getItem('token'),
      userInfo: getUserInfo(),
    },
  },
  {
    name: 'order-system',
    entry: '//localhost:8082',
    container: '#subapp-container',
    activeRule: '/order',
    props: { apiBaseUrl: '/api/order' },
  },
  {
    name: 'product-show',
    entry: '//localhost:8083',
    container: '#subapp-container',
    activeRule: '/product',
  },
]);

// 2. 初始化全局状态（可选）
const actions = initGlobalState({
  user: null,
  permissions: [],
});

// 监听状态变化
actions.onGlobalStateChange((state, prev) => {
  console.log('[主应用] 全局状态变更:', state);
});

// 3. 启动 qiankun
start({
  prefetch: 'all',          // 预加载所有子应用资源
  sandbox: {                 // JS 沙箱配置
    strictStyleIsolation: true, // 开启严格的样式隔离（Shadow DOM）
    experimentalStyleIsolation: true, // 实验性样式隔离
  },
  singular: true,            // 是否为单实例场景（同屏只渲染一个子应用）
});

2.2 qiankun 子应用适配

qiankun 的子应用需要按照规范暴露生命周期钩子。对于不同的框架（Vue、React等），适配方式略有不同，但核心都是导出 bootstrap、mount、unmount 三个生命周期函数。qiankun 通过 import-html-entry 库解析子应用的 HTML 入口，提取并执行其中的脚本和样式。

子应用最重要的配置是打包输出的 library 格式和生命周期导出。以 Vue 3 子应用为例，需要使用 umd 或 system 格式打包，并在入口文件中导出qiankun要求的生命周期。同时，子应用需要支持独立运行（直接访问时也能正常工作）和作为子应用运行两种模式。

// qiankun 子应用（Vue 3）适配示例

// src/main.js - Vue 3 子应用入口
import { createApp } from 'vue';
import App from './App.vue';
import router from './router';

let app = null;
let routerInstance = null;

// 导出 qiankun 生命周期钩子
export async function bootstrap() {
  console.log('[Vue子应用] bootstrap');
}

export async function mount(props) {
  console.log('[Vue子应用] mount', props);
  
  // 创建 Vue 应用实例
  app = createApp(App);
  routerInstance = router;
  
  // 使用主应用传递的路由前缀
  if (props.basePath) {
    routerInstance = router; // 实际项目中需配置 base
  }
  
  app.use(routerInstance);
  app.mount(props.container ? props.container.querySelector('#app') : '#app');
}

export async function unmount() {
  console.log('[Vue子应用] unmount');
  if (app) {
    app.unmount();
    app = null;
  }
}

// 独立运行时（非qiankun环境）
if (!window.__POWERED_BY_QIANKUN__) {
  mount({});
}

// ============ webpack 配置 ============
// vue.config.js
const { defineConfig } = require('@vue/cli-service');

module.exports = defineConfig({
  transpileDependencies: true,
  devServer: {
    port: 8081,
    headers: {
      'Access-Control-Allow-Origin': '*', // 允许跨域（qiankun通过fetch加载资源）
    },
  },
  configureWebpack: {
    output: {
      library: 'user-center',      // 子应用名称，需与注册时一致
      libraryTarget: 'umd',        // 输出格式为 umd
      chunkLoadingGlobal: 'webpackJsonp_user-center', // 避免 chunk 冲突
    },
  },
});

2.3 qiankun 沙箱机制深度解析

qiankun 的沙箱机制是其核心技术之一，用于隔离不同子应用的 JavaScript 执行环境，防止全局变量污染。qiankun 提供了两种沙箱实现：快照沙箱（SnapshotSandbox）适用于不支持 Proxy 的环境，代理沙箱（ProxySandbox）利用 ES6 Proxy 实现对 window 对象的代理，是现代浏览器的首选方案。

代理沙箱的工作原理是：为每个子应用创建一个假的 window 对象（通过 Proxy 代理），子应用对全局变量的读写操作都会被拦截和记录。当子应用卸载时，可以恢复到之前的全局状态，从而实现子应用之间的环境隔离。这种机制使得多个子应用可以安全地在同一页面中运行，互不干扰。

// qiankun 沙箱机制模拟实现

// ============ 快照沙箱（兼容方案）============
class SnapshotSandbox {
  constructor(name) {
    this.name = name;
    this.proxy = window;
    this.globalSnapshot = {}; // 全局状态快照
    this.modifiedMap = {};   // 修改记录
  }

  // 激活沙箱：保存当前全局状态快照
  active() {
    this.globalSnapshot = {};
    // 遍历当前 window 上的属性，保存快照
    for (const key in window) {
      if (window.hasOwnProperty(key)) {
        this.globalSnapshot[key] = window[key];
      }
    }
    console.log(`[${this.name}] 沙箱激活，已保存快照`);
  }

  // 卸载沙箱：恢复全局状态
  inactive() {
    // 恢复被修改的属性
    for (const key in window) {
      if (window.hasOwnProperty(key) && !(key in this.globalSnapshot)) {
        delete window[key]; // 删除新增的属性
      } else if (this.globalSnapshot[key] !== window[key]) {
        window[key] = this.globalSnapshot[key]; // 恢复修改的属性
      }
    }
    console.log(`[${this.name}] 沙箱卸载，已恢复状态`);
  }
}

// ============ 代理沙箱（现代方案）============
class ProxySandbox {
  constructor(name) {
    this.name = name;
    const fakeWindow = Object.create(null); // 创建空白对象作为假的 window
    
    // 使用 Proxy 代理 fakeWindow
    this.proxy = new Proxy(fakeWindow, {
      set: (target, prop, value) => {
        // 记录修改
        target[prop] = value;
        console.log(`[${this.name}] 设置全局变量: ${prop} =`, value);
        return true;
      },
      get: (target, prop) => {
        // 优先从 fakeWindow 读取，读不到则从真实 window 读取
        if (prop in target) {
          return target[prop];
        }
        return window[prop];
      },
      // 防止通过 delete 删除真实 window 的属性
      deleteProperty: (target, prop) => {
        delete target[prop];
        return true;
      },
    });
    
    // 绑定必要的全局 API 到 fakeWindow
    this.proxy.document = window.document;
    this.proxy.addEventListener = window.addEventListener.bind(window);
    this.proxy.removeEventListener = window.removeEventListener.bind(window);
  }
}

// 使用示例
const sandbox = new ProxySandbox('user-center');
const proxyWindow = sandbox.proxy;

proxyWindow.myGlobalVar = 'hello'; // 不会影响真实 window.myGlobalVar
console.log(proxyWindow.myGlobalVar); // 'hello'
console.log(window.myGlobalVar); // undefined

2.4 qiankun 样式隔离方案

qiankun 提供了多种样式隔离方案来解决子应用之间的 CSS 冲突问题。最常用的是严格样式隔离模式（基于 Shadow DOM）和实验性样式隔离（运行时动态改写 CSS 选择器前缀）。此外，qiankun 还支持通过 BEM 命名约定、CSS Modules 等工程化手段来辅助实现样式隔离。

严格样式隔离（strictStyleIsolation）利用 Shadow DOM 的天然隔离特性，将子应用的 DOM 和 CSS 完全封装在一个独立的 Shadow Tree 中。然而，这种方案存在兼容性问题：某些 UI 框架（如 Ant Design）的动态弹窗（Modal、Select 下拉框等）无法正确渲染在 Shadow DOM 内部，因为这些组件通常渲染到 document.body 上。

// qiankun 样式隔离配置与原理

// ============ 方案1：严格样式隔离（Shadow DOM）============
start({
  sandbox: {
    strictStyleIsolation: true, // 开启 Shadow DOM 隔离
  },
});

// 原理：qiankun 会将子应用的容器元素转换为 Shadow Host
// <div id="subapp-container">
//   #shadow-root (open)
//     <link rel="stylesheet" href="app.css">
//     <div id="app">...</div>
// </div>

// 优点：完全隔离，100% 无样式冲突
// 缺点：
// 1. 弹窗类组件无法穿透 Shadow DOM
// 2. 部分 CSS 选择器（如 :host-context）需要适配
// 3. 字体、图标等可能需要额外处理

// ============ 方案2：实验性样式隔离 ============
start({
  sandbox: {
    experimentalStyleIsolation: true, // 改写 CSS 选择器
  },
});

// 原理：qiankun 会改写子应用 CSS 选择器，添加前缀
// 原始 CSS: .app-header { color: red; }
// 改写后:   div[data-qiankun="user-center"] .app-header { color: red; }

// qiankun 内部实现（简化版）
function rewriteCSS(cssText, appName) {
  const prefix = `div[data-qiankun="${appName}"]`;
  // 使用正则匹配所有选择器，添加前缀
  return cssText.replace(/([^{}+\n]+)(,|{)/g, (match, selector, end) => {
    return `${prefix} ${selector.trim()}${end}`;
  });
}

// ============ 方案3：工程化手段 ============
// 1. CSS Modules（推荐）
// webpack.config.js
module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              modules: {
                localIdentName: '[name]__[local]__[hash:base64:5]',
              },
            },
          },
        ],
      },
    ],
  },
};

// 2. BEM 命名约定
// .user-center__header { }  /* Block__Element */
// .user-center__header--active { }  /* Block__Element--Modifier */

三、MicroApp（京东）Web Components方案

3.1 MicroApp 设计理念

MicroApp 是京东开源的微前端框架，它采用了与 qiankun 完全不同的技术路线——基于 Web Components 标准实现微前端。MicroApp 的核心思想是将子应用封装为 Custom Element（自定义元素），利用 Web Components 的原生隔离能力来实现微前端架构。这种设计使得 MicroApp 更加轻量，不需要 JS 沙箱和样式隔离的复杂实现。

与 qiankun 相比，MicroApp 的最大特点是更贴近 Web 标准。它不需要子应用修改入口文件来暴露生命周期，而是直接将子应用打包为 Web Component，主应用通过 HTML 标签的方式使用子应用。这种方式降低了子应用的接入成本，也使得子应用可以更容易地在不同框架之间复用。

// MicroApp 主应用使用示例

// 1. 安装 MicroApp
// npm install @micro-zoe/micro-app --save

// 2. 主应用入口（可以是任何框架，甚至原生HTML）
import microApp from '@micro-zoe/micro-app';

// 不需要像 qiankun 那样注册子应用
// MicroApp 采用声明式使用，直接在模板中使用标签

// ============ HTML 方式使用 ============
/*
<!DOCTYPE html>
<html>
<head>
  <script src="https://unpkg.com/@micro-zoe/micro-app/dist/micro-app.js"></script>
</head>
<body>
  <!-- 直接使用 micro-app 标签 -->
  <micro-app 
    name="user-center" 
    url="http://localhost:8081/" 
    baseroute="/user"
  ></micro-app>
  
  <!-- 路由控制显示/隐藏 -->
  <micro-app 
    v-if="currentRoute === '/order'" 
    name="order-system" 
    url="http://localhost:8082/"
  ></micro-app>
</body>
</html>
*/

// ============ Vue 3 主应用示例 ============
/*
<template>
  <div id="app">
    <h1>主应用</h1>
    <micro-app 
      name="vue3-app" 
      url="http://localhost:3001/" 
      :data="microAppData"
      @datachange="onDataChange"
    />
  </div>
</template>

<script setup>
import { ref } from 'vue';

const microAppData = ref({
  token: 'xxx',
  userInfo: { name: 'BOSS' }
});

const onDataChange = (e) => {
  console.log('子应用发送的数据:', e.detail.data);
};
</script>
*/

3.2 MicroApp 子应用适配

MicroApp 的子应用适配极为简单，不需要像 qiankun 那样导出生命周期钩子。子应用只需要正常开发，通过简单的配置即可接入。MicroApp 通过解析子应用的 HTML 入口，提取其中的 script 和 link 标签，然后利用 Web Components 的 Shadow DOM 进行隔离渲染。

子应用的打包配置也相对简单，主要是设置合适的 publicPath（因为资源路径可能发生变化）。MicroApp 支持多种框架（Vue、React、Angular、Vite等），适配成本极低。对于 Vite 构建的子应用，MicroApp 还提供了专门的插件来处理模块化的脚本加载问题。

// MicroApp 子应用（Vue 3）适配示例

// ============ 子应用不需要修改入口文件 ============
// src/main.js - 正常开发即可
import { createApp } from 'vue';
import App from './App.vue';
import router from './router';

const app = createApp(App);
app.use(router);
app.mount('#app');

// 独立运行时
// 不需要判断 window.__POWERED_BY_MICRO_APP

// ============ vite.config.js 配置 ============
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import { createMicroAppPlugin } from '@micro-zoe/micro-app-plugin';

export default defineConfig({
  plugins: [
    vue(),
    createMicroAppPlugin(), // MicroApp 的 Vite 插件
  ],
  server: {
    port: 3001,
    cors: true, // 允许跨域
  },
  base: 'http://localhost:3001/', // 设置基础路径
});

// ============ webpack 子应用配置 ============
// vue.config.js
const { defineConfig } = require('@vue/cli-service');

module.exports = defineConfig({
  transpileDependencies: true,
  devServer: {
    port: 8081,
    headers: {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
    },
  },
  // MicroApp 不需要设置 library 和 libraryTarget
  // 子应用就是一个普通的 Web 应用
  configureWebpack: {
    output: {
      // 只需要设置 publicPath，确保资源路径正确
      publicPath: 'http://localhost:8081/',
    },
  },
});

// ============ 子应用向主应用通信 ============
// 在子应用中发送数据给主应用
// 使用 CustomEvent 发送数据
const sendToMainApp = (data) => {
  window.dispatchEvent(
    new CustomEvent('micro-app-message', { detail: data })
  );
};

// 监听主应用发送的数据
window.addEventListener('micro-app-data', (e) => {
  console.log('收到主应用数据:', e.detail);
});

3.3 MicroApp 数据通信机制

MicroApp 提供了多种数据通信方式，包括基于属性的数据传递（类似 React 的 props）、全局数据通信（类似 qiankun 的全局状态）以及自定义事件通信。其中，属性传递是最推荐的方式，它符合 Web Components 的标准用法，数据流向清晰。

MicroApp 的全局通信基于发布-订阅模式，主应用可以设置全局数据，所有子应用都能接收到数据变更通知。同时，子应用也可以向主应用发送数据，形成双向通信。这种设计既保证了数据流的清晰性，又提供了足够的灵活性来处理复杂的通信场景。

// MicroApp 数据通信完整示例

// ============ 方式1：属性传递（推荐）============
// 主应用
import microApp from '@micro-zoe/micro-app';

// 发送数据：通过 data 属性
const App = () => {
  const [data, setData] = useState({ token: 'abc123', userId: '1001' });
  
  return (
    <micro-app 
      name="app1" 
      url="http://localhost:3001/"
      data={data}  // 数据作为属性传递
    />
  );
};

// 子应用接收数据
// 在子应用中监听属性变化
const app = document.querySelector('micro-app[name="app1"]');
app.addEventListener('datachange', (e) => {
  console.log('收到数据:', e.detail.data);
  // e.detail.data = { token: 'abc123', userId: '1001' }
});

// ============ 方式2：全局通信 ============
// 主应用设置全局数据
microApp.setGlobalData({ 
  theme: 'dark', 
  locale: 'zh-CN',
  permissions: ['read', 'write'] 
});

// 子应用获取全局数据
const globalData = microApp.getGlobalData();
console.log(globalData.theme); // 'dark'

// 子应用监听全局数据变化
microApp.addGlobalDataListener((data) => {
  console.log('全局数据变更:', data);
});

// 子应用修改全局数据（需主应用授权）
microApp.setGlobalData({ theme: 'light' });

// ============ 方式3：自定义事件 ============
// 子应用发送事件
window.microApp?.dispatch({ type: 'USER_LOGIN', payload: { user: 'BOSS' } });

// 主应用监听子应用事件
document.querySelector('micro-app[name="app1"]')
  .addEventListener('datachange', (e) => {
    console.log('子应用数据变更:', e.detail);
  });

// ============ 数据通信架构图 ============
/*
┌─────────────┐        属性传递         ┌─────────────┐
│   主应用     │ ────────────────────▶  │  子应用 A   │
│             │                        │             │
│             │ ◀────────────────────   │             │
│             │    自定义事件响应        │             │
└─────────────┘                        └─────────────┘
       │                                     
       │ 全局数据                           
       ▼                                     
┌─────────────┐                        ┌─────────────┐
│  全局状态   │ ────────────────────▶  │  子应用 B   │
│   (Store)   │                        │             │
└─────────────┘                        └─────────────┘
*/

3.4 MicroApp 与 qiankun 的核心差异

MicroApp 和 qiankun 虽然都是微前端框架，但设计理念和技术实现有本质区别。qiankun 基于 Single-SPA，通过 JS 入口和生命周期管理来实现微前端，需要 JS 沙箱和样式隔离等机制；而 MicroApp 基于 Web Components，利用浏览器原生的组件化能力，天然具备隔离性，实现更加简洁。

从接入成本来看，MicroApp 明显更低，子应用几乎不需要改造；从隔离能力来看，MicroApp 的 Shadow DOM 隔离更加彻底；从生态成熟度来看，qiankun 由于发布更早，社区案例更多。选择哪个框架，需要根据项目具体情况权衡。

// MicroApp vs qiankun 核心差异对比

// ============ 架构设计差异 ============
/*
qiankun 架构：
┌──────────────────────────────────────┐
│           主应用（基座）              │
│  ┌────────────────────────────────┐ │
│  │  registerMicroApps()           │ │
│  │  start()                       │ │
│  │  JS沙箱 (Proxy/快照)           │ │
│  │  样式隔离 (重写CSS/Shadow DOM) │ │
│  └────────────────────────────────┘ │
│  ┌─────────┐ ┌─────────┐ ┌────────┐│
│  │子应用 A │ │子应用 B │ │子应用 C││
│  │(需适配) │ │(需适配) │ │(需适配)││
│  └─────────┘ └─────────┘ └────────┘│
└──────────────────────────────────────┘

MicroApp 架构：
┌──────────────────────────────────────┐
│           主应用（容器）              │
│  ┌────────────────────────────────┐ │
│  │  <micro-app> 标签声明式使用  │ │
│  │  无需注册，无需start           │ │
│  │  原生 Web Components 隔离      │ │
│  └────────────────────────────────┘ │
│  ┌─────────┐ ┌─────────┐ ┌────────┐│
│  │子应用 A │ │子应用 B │ │子应用 C││
│  │(无适配) │ │(无适配) │ │(无适配)││
│  └─────────┘ └─────────┘ └────────┘│
└──────────────────────────────────────┘
*/

// ============ 代码侵入性对比 ============
// qiankun 子应用必须导出生命周期
export async function bootstrap() { /* ... */ }
export async function mount() { /* ... */ }
export async function unmount() { /* ... */ }

// MicroApp 子应用无需任何修改
// 原来的代码原封不动即可运行

// ============ 兼容性对比 ============
// qiankun: 支持 IE11+（使用快照沙箱时）
// MicroApp: 不支持 IE（依赖 Web Components / Proxy）

// ============ 性能对比 ============
// qiankun: 首次加载需要执行 JS 沙箱初始化，有一定开销
// MicroApp: 利用原生 Web Components，性能更好，但 Shadow DOM 有渲染开销

// 选择建议：
// 1. 需要兼容 IE → qiankun
// 2. 使用 Vite 构建 → MicroApp（支持更好）
// 3. 子应用需要高度定制 → qiankun（控制粒度更细）
// 4. 追求接入简单 → MicroApp（几乎零成本接入）

四、Webpack Module Federation原理

4.1 Module Federation 核心概念

Webpack 5 引入的 Module Federation（模块联邦）是一种全新的微前端实现方案，它允许不同的构建

Webpack 5 引入的 Module Federation（模块联邦）是一种全新的微前端实现方案，它允许不同的构建产物在运行时动态加载彼此的模块，无需将依赖打包到自己的 bundle 中。与 qiankun 和 MicroApp 不同，Module Federation 是在构建阶段就确定了模块共享关系，通过远程模块（remote）和宿主（host）的概念来实现微前端架构。

Module Federation 的核心思想是模块共享而非应用隔离。它允许一个应用（host）在运行时从另一个应用（remote）加载模块，这些模块可以是组件、工具函数、甚至整个页面。这种方式使得代码复用更加高效，因为共享的依赖（如 React、Vue）只需要加载一次，就可以被多个应用共享使用。

// Webpack Module Federation 核心配置

// ============ remote 应用配置（提供模块的应用）============
// webpack.config.js - remote 应用（如：组件库、用户中心）
const { ModuleFederationPlugin } = require('@module-federation/webpack');

module.exports = {
  mode: 'development',
  devServer: {
    port: 3001,
    headers: {
      'Access-Control-Allow-Origin': '*',
    },
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'userCenter',          // 模块名称（全局变量名）
      filename: 'remoteEntry.js',  // 远程入口文件名
      exposes: {                   // 暴露的模块
        './UserInfo': './src/components/UserInfo.jsx',
        './UserAvatar': './src/components/UserAvatar.jsx',
        './userService': './src/services/user.js',
      },
      shared: {                    // 共享的依赖
        react: { singleton: true },   // singleton: 只加载一个实例
        'react-dom': { singleton: true },
      },
    }),
  ],
};

// ============ host 应用配置（消费模块的应用）============
// webpack.config.js - host 应用（主应用）
const { ModuleFederationPlugin } = require('@module-federation/webpack');

module.exports = {
  mode: 'development',
  devServer: {
    port: 3000,
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {                   // 远程模块声明
        userCenter: 'userCenter@http://localhost:3001/remoteEntry.js',
        orderSystem: 'orderSystem@http://localhost:3002/remoteEntry.js',
      },
      shared: {                    // 共享的依赖（需与remote一致）
        react: { singleton: true },
        'react-dom': { singleton: true },
      },
    }),
  ],
};

// ============ host 应用中使用远程模块 ============
// App.jsx
import React, { Suspense } from 'react';

// 动态导入远程模块
const UserInfo = React.lazy(() => import('userCenter/UserInfo'));
const UserAvatar = React.lazy(() => import('userCenter/UserAvatar'));

function App() {
  return (
    <div>
      <h1>主应用</h1>
      <Suspense fallback={<div>加载中...</div>}>
        <UserAvatar userId="1001" />
        <UserInfo userId="1001" />
      </Suspense>
    </div>
  );
}

4.2 Module Federation 运行时原理

Module Federation 的运行时原理基于 Webpack 的模块加载机制。当 host 应用需要加载 remote 模块时，会先加载 remote 应用的 remoteEntry.js 文件，该文件包含了 remote 应用暴露的所有模块信息。然后，host 应用通过 Webpack 的 __webpack_require__ 机制来加载具体的模块代码。

关键概念是共享作用域（Shared Scope）和初始化容器（Initialized Container）。当 host 应用加载 remote 模块时，会检查共享依赖的版本，如果满足条件（如 semver 兼容），则复用已有的依赖；否则，会加载 remote 应用自带的依赖版本。这种机制既保证了依赖共享，又处理了版本冲突问题。

// Module Federation 运行时机制详解

// ============ remoteEntry.js 结构（简化）============
/*
(function() {
  'use strict';
  var __webpack_module_cache__ = {};
  
  // remote 应用的模块定义
  var __webpack_modules__ = {
    './src/components/UserInfo.jsx': (module, exports, __webpack_require__) => {
      // UserInfo 组件代码
      module.exports = function UserInfo(props) {
        return React.createElement('div', null, 'User: ' + props.name);
      };
    },
    './src/services/user.js': (module, exports, __webpack_require__) => {
      // userService 代码
      module.exports = { getUser: () => ({}) };
    },
  };
  
  // 暴露的模块映射
  var moduleMap = {
    './UserInfo': () => __webpack_modules__['./src/components/UserInfo.jsx'],
    './userService': () => __webpack_modules__['./src/services/user.js'],
  };
  
  // 全局注册 remote 应用
  window.userCenter = {
    get: (module) => moduleMap[module](),
    init: (shareScope) => { /* 初始化共享作用域 */ },
  };
})();
*/

// ============ host 加载 remote 的流程 ============
async function loadRemoteModule() {
  // 1. 加载 remoteEntry.js
  await loadScript('http://localhost:3001/remoteEntry.js');
  
  // 2. 初始化共享作用域
  const shareScope = { /* React, ReactDOM 等共享依赖 */ };
  window.userCenter.init(shareScope);
  
  // 3. 获取远程模块工厂函数
  const factory = window.userCenter.get('./UserInfo');
  
  // 4. 执行工厂函数，获取模块导出
  const module = {};
  factory(module);
  const UserInfo = module.exports;
  
  return UserInfo;
}

// ============ 共享依赖版本协商 ============
// Webpack 在运行时会自动处理共享依赖的版本
// 规则：
// 1. 如果 host 和 remote 依赖版本兼容 → 使用 host 的版本
// 2. 如果不兼容 → remote 使用自己的版本
// 3. singleton: true → 全局只允许一个实例

const sharedConfig = {
  react: {
    singleton: true,      // 单例模式
    requiredVersion: '^18.0.0', // 要求版本 >= 18.0.0
    strictVersion: true,  // 版本不匹配时报错（而非警告）
  },
};

4.3 Module Federation 高级特性

Module Federation 提供了许多高级特性，如动态远程容器（Dynamic Remote Containers）、双向共享（Bidirectional Sharing）和嵌套容器（Nested Containers）。动态远程容器允许在运行时决定加载哪个 remote 应用，这对于实现 A/B 测试、灰度发布等场景非常有用。

另一个强大的特性是模块预加载（Prefetching）。通过在 remoteEntry.js 中声明预加载依赖，可以在空闲时间提前加载可能用到的远程模块，从而提升用户体验。此外，Module Federation 还支持 TypeScript 类型共享，使得跨应用的模块调用能够获得完整的类型提示。

// Module Federation 高级用法

// ============ 动态远程容器 ============
// 不再在 webpack 配置中静态声明 remote
// 而是在运行时动态加载

// runtime-dynamic-remote.js
function loadRemoteApp(url, scope) {
  return new Promise((resolve, reject) => {
    // 动态加载 script
    const script = document.createElement('script');
    script.src = url;
    script.onload = () => {
      // 初始化共享作用域
      const proxy = { ... };
      window[scope].init(proxy);
      resolve(window[scope]);
    };
    script.onerror = reject;
    document.head.appendChild(script);
  });
}

// 使用示例：根据路由动态加载
const routes = [
  {
    path: '/user',
    component: () => loadRemoteApp('http://localhost:3001/remoteEntry.js', 'userCenter')
      .then(container => container.get('./UserPage'))
      .then(factory => factory()),
  },
];

// ============ 双向共享（Bidirectional Sharing）============
// 配置中同时作为 host 和 remote
new ModuleFederationPlugin({
  name: 'app1',
  filename: 'remoteEntry.js',
  exposes: {
    './Button': './src/Button.jsx',
  },
  remotes: {
    app2: 'app2@http://localhost:3002/remoteEntry.js',
  },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
    // 允许覆盖共享模块的提供者
    lodash: {
      singleton: true,
      version: '4.17.21',
      get: () => require('lodash'), // 自定义获取方式
    },
  },
});

// ============ 预加载策略 ============
// 使用 webpack 的 magic comment 预加载
const UserPage = React.lazy(() => 
  import(/* webpackPrefetch: true */ 'userCenter/UserPage')
);

// 或者在初始化时预加载
window.userCenter.get('./HeavyComponent').then(factory => {
  // 预加载但不执行
  const module = { exports: {} };
  // 暂不调用 factory(module)
});

五、三种方案技术对比

5.1 架构设计对比

三种微前端方案在架构设计上有本质区别。qiankun 基于 Single-SPA，采用"主从架构 + JS沙箱"的设计；MicroApp 基于 Web Components，采用"声明式标签 + Shadow DOM隔离"的设计；Module Federation 基于 Webpack 5，采用"模块共享 + 运行时加载"的设计。理解这些差异有助于选择最适合项目的方案。

从隔离粒度来看，qiankun 和 MicroApp 都是应用级别的隔离（整个子应用作为一个单元），而 Module Federation 是模块级别的隔离（可以共享任意粒度的模块）。从技术依赖来看，qiankun 和 MicroApp 都是框架级别的封装，需要引入额外的库；而 Module Federation 是构建工具级别的支持，没有额外的运行时库。

5.2 开发体验对比

开发体验是选择微前端方案的重要考量因素。好的开发体验应该包括：简单的接入方式、清晰的调试信息、完善的热更新支持、以及良好的 TypeScript 支持。在这方面，三种方案各有优劣。

qiankun 由于发展较早，文档完善，社区案例丰富，调试工具也相对成熟。MicroApp 的接入成本最低，几乎零改造，对于有大量存量项目的团队非常友好。Module Federation 作为 Webpack 5 的内置功能，与构建工具深度集成，但在调试和错误处理方面还有提升空间。

六、性能、开发体验、生态对比

6.1 性能对比分析

微前端架构的性能考量主要包括：首屏加载时间、运行时内存占用、子应用切换速度以及共享依赖利用率。不同的方案在这些指标上表现不同，选择时需要根据实际场景权衡。

Module Federation 在依赖共享方面有明显优势，相同依赖只加载一次，可以有效减少总包体积。qiankun 和 MicroApp 由于是完整的应用隔离，每个子应用都会打包自己的依赖，可能导致重复加载。但在子应用切换方面，qiankun 和 MicroApp 由于有缓存机制，切换速度更快。

6.2 生态与社区对比

生态成熟度直接影响方案的长期可用性。qiankun 作为蚂蚁集团出品，经过大量内部项目验证，社区活跃度高，问题解决速度快。MicroApp 是京东开源，虽然相对较新，但发展迅速，在 Vite 支持方面有独特优势。Module Federation 作为 Webpack 5 的官方功能，得到了 Webpack 团队的持续维护，生态最为稳定。

在选择方案时，还需要考虑团队技术栈。如果团队主要使用 Vite 构建，MicroApp 是更好的选择；如果团队深度使用 Webpack 5，Module Federation 可以无缝集成；如果需要兼容老项目或IE浏览器，qiankun 是唯一选择。

七、实战选型建议与落地踩坑

7.1 选型决策树

选择微前端方案时，建议按照以下决策树进行：首先明确技术栈（是否使用Vite、是否需要兼容IE），然后评估团队能力（是否有Webpack配置经验），最后考虑项目特点（是否需要模块级共享、是否存量项目改造）。根据这个决策树，可以得出最适合的方案。

对于大型存量项目改造，推荐使用 qiankun，因为它兼容性好，社区案例多，遇到问题容易找到解决方案。对于新项目且使用Vite，推荐 MicroApp，接入成本最低。对于组件库共享、模块级复用场景，Module Federation 是最佳选择，因为它天生就是为模块共享设计的。

// 微前端选型决策树（代码化表达）

function selectMicroFrontendSolution(requirements) {
  const { techStack, team, project } = requirements;
  
  // 决策树
  if (project.needIE11) {
    return 'qiankun'; // 只有qiankun支持IE11
  }
  
  if (techStack.builder === 'vite') {
    return 'MicroApp'; // Vite项目首选MicroApp
  }
  
  if (project.moduleSharing) {
    return 'Module Federation'; // 需要模块级共享
  }
  
  if (project.legacyMigration) {
    return 'qiankun'; // 老项目迁移，qiankun案例多
  }
  
  if (team.webpackExperience < 3) {
    return 'MicroApp'; // 降低接入成本
  }
  
  // 默认推荐
  return 'qiankun'; // 生态最成熟，文档最完善
}

// 使用案例
const solution1 = selectMicroFrontendSolution({
  techStack: { builder: 'vite' },
  team: { webpackExperience: 2 },
  project: { needIE11: false, moduleSharing: false },
});
console.log(solution1); // 'MicroApp'

// 选型矩阵（快速参考）
const SELECTION_MATRIX = {
  '大型B端系统': 'qiankun',
  '新项目+Vue3+Vite': 'MicroApp',
  '组件库共享': 'Module Federation',
  'IE11兼容需求': 'qiankun',
  '存量项目迁移': 'qiankun',
  '多技术栈共存': 'qiankun 或 MicroApp',
  '极致性能优化': 'Module Federation',
};

7.2 落地踩坑指南

微前端落地过程中会遇到各种问题，提前了解这些坑可以节省大量调试时间。常见问题包括：样式冲突（即使有隔离机制也可能出问题）、JS全局变量污染（沙箱不完美的边缘情况）、公共依赖版本冲突、路由同步问题、以及开发环境代理配置等。

针对 qiankun，最常见的坑是子应用静态资源404（需要正确配置 publicPath）和弹窗组件无法显示（因为渲染在body上，不在Shadow DOM内）。针对 MicroApp，主要问题是某些UI框架不兼容 Shadow DOM。针对 Module Federation，主要挑战是共享依赖版本协商失败和TypeScript类型丢失。

// 微前端落地常见坑与解决方案

// ============ 坑1：qiankun子应用静态资源404 ============
// 原因：子应用打包时资源路径不正确
// 解决：设置正确的 publicPath
// webpack.config.js
module.exports = {
  output: {
    publicPath: 'http://localhost:8081/', // 子应用访问地址
  },
};

// ============ 坑2：qiankun弹窗无法显示 ============
// 原因：Ant Design Modal默认渲染到document.body
// 解决：配置弹窗的 getContainer
import { Modal } from 'antd';

function App() {
  return (
    <div>
      <Modal 
        title="提示" 
        getContainer={() => document.querySelector('#subapp-container')}
      >
        内容
      </Modal>
    </div>
  );
}

// ============ 坑3：MicroApp中UI框架样式丢失 ============
// 原因：某些UI框架用到了document样式的查询
// 解决：关闭严格样式隔离，使用实验性隔离
MicroApp.start({
  plugins: {
    modules: [
      // 适配antd
      {
        loader(code, url) {
          if (url.includes('antd')) {
            code = code.replace(/document\.body/g, 'document.currentScript.ownerDocument.body');
          }
          return code;
        }
      }
    ]
  }
});

// ============ 坑4：Module Federation共享依赖冲突 ============
// 原因：host和remote的React版本不兼容
// 解决：统一版本或使用 strictVersion: false
new ModuleFederationPlugin({
  shared: {
    react: {
      singleton: true,
      requiredVersion: '^18.0.0',
      strictVersion: false, // 版本不匹配时警告而非报错
    },
  },
});

// ============ 坑5：开发环境代理配置 ============
// qiankun开发时子应用跨域问题
// vue.config.js
module.exports = {
  devServer: {
    proxy: {
      '/api': {
        target: 'http://api.example.com',
        changeOrigin: true,
      },
    },
    // 允许跨域（qiankun通过fetch加载）
    headers: {
      'Access-Control-Allow-Origin': '*',
    },
  },
};

7.3 最佳实践总结

基于大量项目实践，总结以下微前端最佳实践：1. 渐进式接入——不要一次性全部微前端化，先从独立功能模块开始；2. 统一设计规范——虽然技术栈可以不同，但UI规范应该统一；3. 建立共享组件库——将公共组件抽离为独立npm包或Module Federation模块；4. 完善监控体系——为每个子应用添加独立的错误监控和性能监控。

最后，微前端不是银弹。在决定使用微前端之前，请务必评估：团队规模是否真的需要？业务复杂度是否值得引入额外复杂度？如果答案是肯定的，那么选择一个适合的方案，遵循最佳实践，微前端一定能给你的项目带来显著的收益。

// 微前端最佳实践 Checklist

const MICRO_FRONTEND_CHECKLIST = {
  // 架构设计
  architecture: [
    '✅ 明确主应用与子应用的边界',
    '✅ 设计清晰的通信机制（避免混乱的全局事件）',
    '✅ 制定统一的路由规范',
    '✅ 规划共享依赖策略（哪些共享，哪些独立）',
  ],
  
  // 开发规范
  development: [
    '✅ 统一代码规范（ESLint + Prettier）',
    '✅ 统一UI设计规范（主题、组件库）',
    '✅ 统一状态管理方案（如果可能）',
    '✅ 制定子应用接入标准文档',
  ],
  
  // 工程化
  engineering: [
    '✅ 搭建统一的CI/CD流水线',
    '✅ 配置子应用独立部署能力',
    '✅ 建立共享组件库（npm或Module Federation）',
    '✅ 配置统一的开发环境代理',
  ],
  
  // 监控与运维
  monitoring: [
    '✅ 接入错误监控（Sentry、Fundebug等）',
    '✅ 配置性能监控（首屏、白屏、卡顿）',
    '✅ 建立日志收集系统',
    '✅ 设置告警规则',
  ],
  
  // 测试
  testing: [
    '✅ 子应用独立测试能力',
    '✅ 集成测试（主子应用联调）',
    '✅ 自动化回归测试',
    '✅ 性能基准测试',
  ],
};

// 打印检查清单
Object.entries(MICRO_FRONTEND_CHECKLIST).forEach(([category, items]) => {
  console.log(`\n📋 ${category.toUpperCase()}`);
  items.forEach(item => console.log(`  ${item}`));
});