二、微前端 - 主流微前端方案对比与选型 ⚖️

第二章：主流微前端方案对比与选型 ⚖️

2.1 技术方案全景图

微前端技术方案可以按照不同的维度进行分类，每种方案都有其独特的优势和适用场景。

2.1.1 基于路由的微前端方案

基于路由的微前端方案是最常见的实现方式，通过路由分发来加载不同的子应用。

代表方案：

• qiankun：基于 single-spa 的企业级微前端框架
• single-spa：微前端框架的鼻祖
• EMP：基于 Module Federation 的微前端解决方案

特点：

• 路由驱动，按需加载
• 应用间相对独立
• 技术栈无关
• 适合大型企业级应用

2.1.2 基于组件的微前端方案

基于组件的微前端方案将子应用作为组件来使用，更加灵活。

代表方案：

• micro-app：基于 Web Components 的微前端框架
• Web Components：浏览器原生支持
• Garfish：字节跳动的微前端框架

特点：

• 组件化开发
• 更灵活的集成方式
• 适合中小型项目
• 学习成本相对较低

2.1.3 基于构建时的微前端方案

基于构建时的微前端方案在构建阶段就确定了应用的关系。

代表方案：

• Webpack Module Federation：Webpack 5 的联邦模块
• Vite Federation：基于 Vite 的联邦模块

特点：

• 构建时确定依赖关系
• 性能最优
• 需要统一技术栈
• 适合技术栈统一的项目

2.1.4 基于运行时的微前端方案

基于运行时的微前端方案在运行时动态加载和管理子应用。

代表方案：

• iframe：传统的隔离方案
• Web Components：浏览器原生支持
• Custom Elements：自定义元素

特点：

• 运行时动态加载
• 隔离性最好
• 性能开销较大
• 适合对隔离性要求极高的场景

2.2 主流方案详细对比

2.2.1 qiankun - 企业级微前端框架

技术特点：

• 基于 single-spa 封装
• 提供完整的微前端解决方案
• 支持多种技术栈
• 内置沙箱机制

优势：

• 功能完整，开箱即用
• 社区活跃，文档完善
• 企业级应用验证
• 支持预加载和缓存

劣势：

• 学习成本较高
• 配置相对复杂
• 对老项目改造有一定成本

适用场景：

• 大型企业级应用
• 多团队协作项目
• 技术栈多样化
• 对稳定性要求高

代码示例：

// 主应用配置
import { registerMicroApps, start } from "qiankun";

registerMicroApps([
  {
    name: "user-center",
    entry: "//localhost:3001",
    container: "#micro-app-container",
    activeRule: "/user",
    props: {
      theme: "light",
      language: "zh-CN",
    },
  },
  {
    name: "product-management",
    entry: "//localhost:3002",
    container: "#micro-app-container",
    activeRule: "/product",
    props: {
      theme: "light",
      language: "zh-CN",
    },
  },
]);

// 启动应用
start({
  sandbox: {
    strictStyleIsolation: true,
    experimentalStyleIsolation: true,
  },
  prefetch: true,
  singular: false,
});

2.2.2 micro-app - 轻量级微前端框架

技术特点：

• 基于 Web Components 实现
• 零配置，开箱即用
• 支持所有技术栈
• 轻量级实现

优势：

• 学习成本低
• 配置简单
• 性能优秀
• 支持所有技术栈

劣势：

• 功能相对简单
• 生态不如 qiankun 丰富
• 企业级特性较少

适用场景：

• 中小型项目
• 快速原型开发
• 技术栈多样化
• 对性能要求高

代码示例：

// 主应用入口文件使用
import microApp from "@micro-zoe/micro-app";

microApp.start();

// 子应用加载
  <!-- 👇 name is the app name, url is the app address -->
  <micro-app name='my-app' url='http://localhost:3000/'></micro-app>

2.2.3 Module Federation - Webpack 5 联邦模块

技术特点：

• Webpack 5 原生支持
• 构建时确定依赖关系
• 性能最优
• 需要统一技术栈

优势：

• 性能最优
• 构建时优化
• 依赖共享
• 共享模块的方式进行通信

劣势：

• 需要 Webpack 5
• 技术栈必须统一
• 学习成本高
• 配置复杂
• 无 css 沙箱和 js 沙箱

适用场景：

• 技术栈统一的项目
• 对性能要求极高
• 大型单体应用拆分
• 团队技术栈一致

代码示例：

// webpack.config.js - 主应用
const ModuleFederationPlugin = require("@module-federation/webpack");

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: "main_app",
      remotes: {
        user_center: "user_center@http://localhost:3001/remoteEntry.js",
        product_management:
          "product_management@http://localhost:3002/remoteEntry.js",
      },
      shared: {
        react: { singleton: true, requiredVersion: "^18.0.0" },
        "react-dom": { singleton: true, requiredVersion: "^18.0.0" },
      },
    }),
  ],
};

// 主应用使用
import React, { Suspense } from "react";

const UserCenterApp = React.lazy(() => import("user_center/App"));

function MainApp() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <UserCenterApp />
    </Suspense>
  );
}

2.2.4 Web Components - 浏览器原生支持

技术特点：

• 标准化
• 浏览器原生支持，将前端应用程序分解为自定义 HTML 元素
• 基于 customEvent 实现通信
• 完全隔离， shadowDOM 天生的作用于隔离
• 未来趋势

优势：

• 浏览器原生支持
• 完全隔离
• 标准化
• 无需额外框架

劣势：

• 功能有限
• 兼容性问题
• 开发体验一般，调试困难，修改样式困难
• 学习成本

适用场景：

• 对隔离性要求极高
• 长期项目
• 标准化要求高
• 未来技术趋势

代码示例：

// 自定义微前端容器
class MicroFrontendContainer extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: "open" });
  }

  connectedCallback() {
    const appName = this.getAttribute("app-name");
    const appEntry = this.getAttribute("app-entry");

    if (appName && appEntry) {
      this.loadApp(appName, appEntry);
    }
  }

  async loadApp(appName, appEntry) {
    try {
      // 动态加载子应用
      const script = document.createElement("script");
      script.src = appEntry;
      script.onload = () => {
        if (window[appName]) {
          window[appName].mount(this.shadowRoot);
        }
      };
      document.head.appendChild(script);
    } catch (error) {
      console.error(`Failed to load app ${appName}:`, error);
    }
  }
}

// 注册自定义元素
customElements.define("micro-frontend-container", MicroFrontendContainer);

// 使用
<micro-frontend-container
  app-name="user-center"
  app-entry="http://localhost:3001/app.js"
></micro-frontend-container>;

2.2.5 iframe - 浏览器原生支持

技术特点：

• 浏览器原生支持
• 完全隔离
• 标准化
• 未来趋势

优势：

• 微前端最简单的方案， 通过 iframe 加载子应用
• 通信可以通过 postMessage 进行通信
• 完美的沙箱机制自带应用隔离

劣势：

• 用户体验差(弹窗只能在 iframe 中、在内部切换刷新就会丢失状态)

适用场景：

2.3 方案选型决策树

2.3.1 选型决策流程

开始
├── 项目规模
│ ├── 大型企业级应用 (>50 人团队)
│ │ ├── 技术栈是否统一？
│ │ │ ├── 是 → Module Federation
│ │ │ └── 否 → qiankun
│ │ └── 对隔离性要求极高？
│ │ ├── 是 → Web Components
│ │ └── 否 → qiankun
│ └── 中小型项目 (<20 人团队)
│ ├── 技术栈是否统一？
│ │ ├── 是 → Module Federation
│ │ └── 否 → micro-app
│ └── 对性能要求极高？
│ ├── 是 → Module Federation
│ └── 否 → micro-app
└── 特殊需求
├── 完全隔离 → Web Components
├── 极致性能 → Module Federation
├── 快速开发 → micro-app
└── 企业级稳定 → qiankun

2.3.2 详细对比表格

方案	学习成本	性能	隔离性	生态	适用场景	推荐指数
qiankun	中等	高	强	丰富	大型企业	⭐⭐⭐⭐⭐
micro-app	低	高	强	一般	中小项目	⭐⭐⭐⭐
Module Federation	高	最高	弱	丰富	技术栈统一	⭐⭐⭐⭐⭐
Web Components	高	最高	最强	原生	追求极致	⭐⭐⭐
single-spa	高	高	中等	丰富	自定义需求	⭐⭐⭐
iframe	低	低	最强	无	简单隔离	⭐⭐

2.3.3 技术栈兼容性对比

方案	React	Vue	Angular	原生 JS	其他框架
qiankun	✅	✅	✅	✅	✅
micro-app	✅	✅	✅	✅	✅
Module Federation	✅	✅	✅	❌	有限
Web Components	✅	✅	✅	✅	✅
single-spa	✅	✅	✅	✅	✅

2.4 实际项目选型案例

2.4.1 大型电商平台 - 选择 qiankun

项目背景：

• 团队规模：100+ 人
• 技术栈：React、Vue、Angular 混合
• 业务复杂度：极高
• 稳定性要求：极高

选型理由：

• 功能完整，企业级特性丰富
• 支持多种技术栈
• 社区活跃，问题解决及时
• 阿里内部大量验证

实施效果：

• 构建时间从 5 分钟降低到 30 秒
• 团队可以独立开发部署
• 新功能上线周期缩短 60%
• 系统稳定性提升 40%

2.4.2 中型 SaaS 平台 - 选择 micro-app

项目背景：

• 团队规模：30 人
• 技术栈：React 为主
• 业务复杂度：中等
• 开发效率要求：高

选型理由：

• 学习成本低，快速上手
• 配置简单，维护成本低
• 性能优秀，用户体验好
• 支持所有技术栈

实施效果：

• 开发效率提升 50%
• 部署频率提升 3 倍
• 团队协作效率提升 40%
• 用户满意度提升 25%

2.4.3 技术栈统一项目 - 选择 Module Federation

项目背景：

• 团队规模：50 人
• 技术栈：React 18 + TypeScript
• 业务复杂度：高
• 性能要求：极高

选型理由：

• 性能最优，用户体验最佳
• 构建时优化，运行时性能好
• 依赖共享，减少重复加载
• 官方支持，技术风险低

实施效果：

• 首屏加载时间减少 60%
• 运行时性能提升 40%
• 包体积减少 30%
• 开发体验显著提升

2.5 选型最佳实践

2.5.1 评估维度

技术维度：

• 学习成本
• 开发效率
• 性能表现
• 维护成本

业务维度：

• 项目规模
• 团队能力
• 业务复杂度
• 稳定性要求

组织维度：

• 团队结构
• 技术栈选择
• 开发流程
• 运维能力

2.5.2 选型建议

新项目：

• 技术栈统一 → Module Federation
• 技术栈多样 → qiankun
• 快速原型 → micro-app
• 长期项目 → Web Components

老项目改造：

• 渐进式改造 → qiankun
• 完全重构 → Module Federation
• 最小改动 → micro-app
• 标准化改造 → Web Components

团队能力：

• 高级团队 → qiankun / Module Federation
• 中级团队 → micro-app
• 初级团队 → micro-app / iframe

2.6 本章小结

本章详细对比了主流的微前端方案，包括 qiankun、micro-app、Module Federation、Web Components 等。每种方案都有其独特的优势和适用场景：

• qiankun：适合大型企业级应用，功能完整，生态丰富
• micro-app：适合中小型项目，学习成本低，配置简单
• Module Federation：适合技术栈统一的项目，性能最优
• Web Components：适合对隔离性要求极高的场景，标准化

选择微前端方案时，需要综合考虑项目规模、团队能力、技术栈、业务需求等多个因素。没有最好的方案，只有最适合的方案。