Webpack 5 引入的 Module Federation 并不是一个普通的代码分割插件，它把模块边界从构建期延伸到了运行时。宿主应用和远程应用不再需要共享同一个仓库或统一发版节奏，远程模块可以独立部署、随时更新，宿主只需通过网络加载一份入口清单。这个能力直接改变了大型前端工程的协作方式，也让微前端从基于路由的粗粒度组合，走向基于模块的细粒度复用。
要理解模块联邦的未来，先要看清它现在解决了什么。传统微前端方案通常以应用为单位进行组合，不同子应用之间即使使用相同的 React 或 Vue，也可能各自打包一份，导致首屏体积膨胀。更麻烦的是，当多个团队同时维护同一个 UI 库时，版本不一致会引发状态丢失或组件渲染异常。Module Federation 通过共享作用域让这些依赖以单例方式运行，同时允许远程模块按需加载，避免了简单的整包复制。
模块联邦解决的核心问题
模块联邦最大的价值在于将部署单元从应用缩小到模块。一个远程应用可以通过 exposes 有选择地公开组件、工具函数、状态管理模块，而宿主应用通过 remotes 声明要消费哪些远程入口。这个过程不需要修改宿主配置后重新构建，远程模块更新后宿主下一次加载即可获得最新实现。
这使得多团队协作的发布节奏可以完全解耦。例如商品团队只负责维护商品卡片组件，结算团队只维护价格计算模块，它们可以独立上线。宿主应用不需要知道这些模块的发布周期，只需要在运行时通过远程入口加载。与基于 iframe 或 JS 入口的微前端方案相比，模块联邦不会创建新的浏览器上下文，样式和状态也能更自然地交互。
依赖共享是另一个容易被忽视的收益。通过 shared 配置，Webpack 会检查宿主和远程应用是否加载了相同版本的依赖。如果版本满足 requiredVersion，则复用已有实例；如果不满足，则会回退到独立加载。这种策略既避免了重复打包，又保留了版本灵活性，为大型系统的渐进式升级提供了缓冲。
Webpack 5 中模块联邦的实现机制
模块联邦的入口文件通常被称为 remoteEntry.js，它本身是一个很小的运行时容器。宿主应用加载这个文件后，可以通过全局对象或共享作用域与远程容器通信。远程容器内部维护了模块工厂、共享依赖元数据以及异步加载逻辑。下面是一个远程应用的典型配置：
// remote-app/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remote_app',
filename: 'remoteEntry.js',
exposes: {
'./ProductCard': './src/components/ProductCard',
'./usePrice': './src/hooks/usePrice',
},
shared: {
react: { singleton: true, requiredVersion: '^18.2.0' },
'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
},
}),
],
};
宿主应用则通过 remotes 声明远程模块的来源。远程地址既可以是固定 URL，也可以在运行时动态生成。固定配置如下：
// host-app/webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host_shell',
remotes: {
catalog: 'remote_app@http://localhost:3001/remoteEntry.js',
},
shared: {
react: { singleton: true, requiredVersion: '^18.2.0' },
'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
},
}),
],
};
在业务代码中，宿主应用可以使用动态导入的方式消费远程模块。Webpack 会把这些导入请求转换为对远程容器接口的调用。无论是同步组件还是异步组件，最终都由统一的运行时机制完成模块获取和依赖解析。
理解这套机制的关键在于共享作用域。远程容器在初始化时会调用 Webpack 注入的 init 函数，把自己挂载到 __webpack_share_scopes__ 上。宿主应用同样会注册自己的共享作用域，两者在加载时互相协商依赖版本。如果宿主已经加载了 React 18，远程组件声明兼容 React 18，那么远程组件就不会重复加载 React，而是直接使用宿主实例。这种协商逻辑是模块联邦能减少重复依赖的核心原因。
模块联邦未来演进方向
模块联邦的长期方向很可能不再局限于 Webpack 本身。Rspack 已经实现了与 Webpack 模块联邦协议兼容的能力，Vite 社区也在通过插件探索类似的运行时模块共享。未来跨构建工具互操作会更加普遍，远程模块可以来自不同构建系统，宿主无需关心远程应用使用什么工具打包，只要它们遵循相同的模块容器协议即可。
浏览器原生的 Import Map 与 ES Module 是另一个重要趋势。模块联邦目前依赖 Webpack 注入的运行时函数来解析远程地址和执行共享协商，但随着浏览器对模块解析能力的增强，一部分工作可能下沉到浏览器层。远程模块的入口可以是一个标准的 ES Module 地址，浏览器负责下载和执行，构建工具只负责生成可预测的模块映射。这种方式能进一步减少运行时体积，也让调试更加透明。
类型安全和运行时契约也会成为重点。目前远程模块的接口变化很难在构建期被发现，往往要等运行时加载失败才会暴露问题。未来可能出现更成熟的类型共享方案，把远程模块的 TypeScript 声明一并发布，宿主在编译阶段就能校验组件属性和函数签名。同时，模块版本协商机制会从简单的 semver 匹配，演进到包含公开接口变更检测的契约校验，降低因接口不兼容导致的线上事故。
部署形态也会影响模块联邦的用法。边缘网络和 CDN 可以让 remoteEntry.js 更靠近用户，降低首屏远程加载延迟。动态配置远程地址则允许根据环境或灰度策略切换模块来源。例如测试环境加载开发版远程模块，生产环境加载稳定版，甚至按用户分组加载不同的实验版本。这些能力让模块联邦不仅是微前端工具，更成为运行时组合平台的基础。
实际落地中的常见问题与应对
模块联邦并非没有代价。远程模块加载失败会导致页面局部不可用，因此需要设计错误边界和降级方案。宿主应用可以通过 React Error Boundary 或 Vue 的 errorCaptured 捕获远程组件异常，并提供占位内容。对于关键模块，还可以预加载多个远程入口，在一个失败时切换到备用地址。
动态远程模块加载通常需要手动初始化共享作用域。下面是一段通用的加载函数，演示了如何从远程容器中获取模块并返回可渲染的组件工厂：
async function loadRemoteComponent(scope, moduleName) {
await window.__webpack_init_sharing__('default');
const container = window[scope];
if (!container) {
throw new Error('Remote container not found: ' + scope);
}
await container.init(window.__webpack_share_scopes__.default);
const factory = await container.get(moduleName);
return factory();
}
这段代码的核心是先初始化宿主共享作用域，再让远程容器挂载到同一作用域，最后调用 get 方法取得模块工厂。实际项目中建议将这类逻辑封装为可复用的加载器，并加入缓存机制，避免每次渲染都重新协商依赖。
网络延迟和版本冲突也需要提前规划。远程入口文件应当设置合理的缓存策略，同时在版本不匹配时提供明确日志，帮助排查是哪个依赖发生了回退。模块联邦的共享配置越清晰，线上问题越容易被定位。未来随着工具链和浏览器能力继续演进，模块联邦的复杂部分会逐渐被框架和平台吸收，开发者的关注点会回到业务模块本身。
Webpack 5Module Federation微前端修改时间：2026-08-26 11:57:43