微前端工程实践：从架构设计到 Module Federation 落地

为什么需要微前端？

随着前端项目复杂度不断提升，单体应用逐渐暴露出明显问题：

• 多团队开发冲突严重
• 构建时间越来越长
• 技术栈升级困难
• 发布周期相互影响

当一个系统包含多个业务域时，微前端成为一种自然演进方向。

一、微前端的本质

微前端的核心思想是：

将一个前端应用拆分为多个独立可运行的子应用。

每个子应用拥有：

• 独立开发
• 独立部署
• 独立运行时

最终由一个“主应用”进行组合。

二、主流实现方案对比

1. iframe 方案

优点：

• 完全隔离
• 安全性强

缺点：

• 通信困难
• 性能差
• UI 不一致

2. qiankun（运行时加载）

qiankun 是基于 single-spa 的微前端框架。

特点：

• 生命周期管理（bootstrap/mount/unmount）
• JS 沙箱
• CSS 隔离

适合后台系统、企业级中台。

3. Module Federation（推荐）

Webpack 5 提供的模块联邦机制。

核心能力：

• 动态加载远程模块
• 共享依赖（React/Vue）
• 按需加载子应用

三、Module Federation 架构模型

典型结构如下：

Host（主应用）
 ├── Remote A（用户系统）
 ├── Remote B（订单系统）
 ├── Remote C（支付系统）

每个 Remote 都可以独立部署。

四、Webpack 配置示例

Host 应用

new ModuleFederationPlugin({
  name: "host",
  remotes: {
    userApp: "userApp@http://localhost:3001/remoteEntry.js"
  },
  shared: {
    react: { singleton: true },
    "react-dom": { singleton: true }
  }
})

Remote 应用

new ModuleFederationPlugin({
  name: "userApp",
  filename: "remoteEntry.js",
  exposes: {
    "./App": "./src/App"
  },
  shared: {
    react: { singleton: true },
    "react-dom": { singleton: true }
  }
})

五、子应用加载方式

Host 中使用：

const UserApp = React.lazy(() => import("userApp/App"))

或者：

<Suspense fallback={"loading"}>
  <UserApp />
</Suspense>

六、微前端通信方案

1. 全局事件（Event Bus）

window.dispatchEvent(new CustomEvent("login", { detail: user }))

2. shared store

const store = {
  user: null
}

3. URL 参数

/user?id=123

七、工程化最佳实践

1. 共享依赖必须 singleton

避免重复加载 React：

shared: {
  react: { singleton: true }
}

2. 子应用必须独立部署

不能依赖主应用构建。

3. 避免强通信

微前端本质是“解耦”，不是“强耦合系统”。

八、常见问题

1. 白屏问题

通常是 remoteEntry 加载失败。

2. 样式污染

解决方式：

• CSS Modules
• Shadow DOM
• scoped CSS

3. 依赖冲突

React / Vue 必须共享 singleton。

九、适用场景

适合：

• 企业级后台系统
• 多团队协作平台
• SaaS 多租户系统
• 超大型业务平台

不适合：

• 小型项目
• 单团队项目

总结

微前端不是“技术炫技”，而是一种组织结构优化方式。

Module Federation 提供了最轻量、最现代的实现方式，是当前 React / Webpack 体系下的主流选择。