什么是模块联邦（Module Federation）？

模块联邦（Module Federation） 是 Webpack 5 引进的一项核心特性。它允许一个 JavaScript 应用程序在运行时（Runtime）动态地加载和运行来自另一个独立构建的应用程序的模块。

在模块联邦之前，前端共享代码的主要方式有两种：

1. 构建时共享（NPM 包）：将公共代码打包成 NPM 包，其他项目 install 并重新打包。缺点是更新成本高，任何公共代码变动都需要依赖方重新安装并重新构建发布。
2. 运行时共享（以 <script> 标签引入大公共库，或 iframe）：缺点是缺乏灵活的代码分割、依赖管理复杂，且 iframe 存在严重的隔离和体验问题。

模块联邦突破了这一限制，它让不同的应用可以像引用本地模块一样，通过网络去异步加载另一个应用暴露出来的模块，并且支持共享公共依赖（如 React、Vue 等），避免重复下载。

---

核心概念

在模块联邦中，应用通常扮演以下三种角色之一（甚至兼具）：

1. Host（宿主/主应用）：消费（消费/引入）其他远程模块的应用。
2. Remote（远程应用）：暴露出自己的模块，供其他应用调用的应用。
3. Shared（共享依赖）：多个应用之间共享的第三方库（例如 react、lodash）。如果 Host 和 Remote 都需要 React，Host 加载过一次后，Remote 就不会重复下载，而是直接复用。

---

核心应用场景

模块联邦最主要的应用场景可以概括为以下四个方面：

1. 微前端架构（Micro-Frontends）—— 最主要的应用场景

• 问题：传统大型单体前端应用随着业务增长，构建极慢，团队协作困难，代码耦合严重。
• 解决方案：利用模块联邦，可以将一个巨大的应用拆分为多个独立开发、独立部署的微应用（例如：主框架应用、订单微应用、用户中心微应用）。
• 优势：
  • 独立部署与热更新：微应用更新代码并部署后，主应用刷新即可直接加载最新代码，主应用完全不需要重新打包。
  • 无缝无感体验：不同于 iframe，模块联邦加载的模块运行在同一个 DOM 树和上下文中，样式和路由可以完美融合。

2. 动态公共组件库 / 设计系统（Design Systems）

• 问题：公司内部的 UI 组件库或业务业务组件库频繁更新，每次更新都要通知各个业务线升级 NPM 包并重新构建发布，推进极其困难。
• 解决方案：将公共组件库作为一个独立的 Remote 应用打包部署。
• 优势：组件库更新后，所有消费该组件库的业务应用在运行时自动获得最新版本的组件，实现零成本瞬间同步（同时可以通过版本控制防止 Breaking Change 搞砸线上）。

3. 共享应用框架 / 壳（Application Shell）

• 场景：公司有数十个内部管理系统，它们拥有相同的页头、页脚、侧边栏导航、登录鉴权逻辑和逻辑控制。
• 解决方案：将“通用壳（Shell）”作为一个 Remote 应用，各个具体业务页面作为 Host 或独立的 Remote。
• 优势：只需维护一份统一的“壳”代码，任何关于全局导航或鉴权逻辑的修改，对所有子系统即时生效。

4. 巨型单体应用的增量编译与构建加速（Monorepo 优化）

• 问题：在极大的 Monorepo 项目中，全量构建可能需要几十分钟。
• 解决方案：将大项目拆分为多个通过模块联邦连接的子模块。
• 优势：开发者在本地开发时，只需要构建自己负责的子模块，其他模块直接加载测试环境/预发环境已经打包好的 Remote 资源。这能将本地编译启动时间从几分钟缩短到几秒钟。

---

总结与优缺点

一句话总结：模块联邦是前端实现去中心化架构、微前端和代码运行时共享的最佳利器之一，它打破了“应用构建边界”，极大提升了大型团队的协同效率和应用扩展性。