Webpack 5发布后，模块联邦（Module Federation）成为最受关注的能力之一。在一些技术社区里，开发者把这种能力戏称为贪婪宇宙，因为它让多个独立构建的应用可以像星系一样共享组件和状态，同时保持各自的发布节奏。这个比喻虽然不在官方文档中，但很好地描述了模块联邦的核心特征：一个应用可以在运行时贪婪地拉取另一个应用暴露出来的模块，而不需要事先安装或编译这些代码。本文不打算停留在术语层面，而是从实际配置、运行机制、性能优化三个角度拆解这一特性。
模块联邦如何构建贪婪的宇宙
传统微前端方案通常依赖iframe、Nginx路由分发或者npm包共享，这些方式要么隔离性过强导致状态难以同步，要么要求所有消费方重新构建并升级依赖。模块联邦改变了这个局面。Webpack 5在编译器层面增加了一个容器概念，每个构建产物都可以成为一个容器，对外声明自己暴露哪些模块，同时也声明自己依赖哪些远程模块。当浏览器加载宿主应用时，Webpack运行时会根据远程入口文件动态地获取模块代码，然后像加载本地模块一样执行它们。
这种机制之所以被称为贪婪宇宙，是因为它打破了应用边界的限制。一个宿主应用可以同时连接多个远程应用，远程应用之间也可以互相引用，形成一个网状结构。模块在运行时被拉取，而不是在构建时被打包进产物。这意味着一个按钮组件可以放在远程应用的仓库里，宿主应用完全不需要知道它在构建时的具体实现，只需要在运行时通过容器接口获取即可。这为大型团队并行开发和独立部署提供了极大的灵活性。
核心配置与容器暴露规则
要使用模块联邦，需要在Webpack配置中引入ModuleFederationPlugin。该插件来自webpack的container模块。下面是一段远程应用的典型配置，它暴露了一个Button组件，并声明了与宿主共享React依赖。
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
// 其余配置省略
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button',
},
shared: {
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
},
}),
],
};
上面配置中的name是容器的全局唯一标识，filename指定远程入口文件的名称，宿主应用会加载这个文件来获取模块清单。exposes字段把本地路径映射为公开路径，远程模块通过这个公开路径进行引用。shared字段则用来声明哪些依赖需要与宿主共享，避免重复加载。singleton表示整个页面只允许存在一份该依赖，requiredVersion则用于版本校验。
宿主应用的配置略有不同，它需要声明remotes来指向远程模块的入口地址。下面是宿主应用配置示例。
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
},
shared: {
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
},
}),
],
};
配置完成后，宿主应用就可以通过动态import来加载远程模块。例如在React中可以使用lazy和Suspense来实现按需加载。
import React, { Suspense, lazy } from 'react';
const RemoteButton = lazy(() => import('remoteApp/Button'));
function App() {
return (
<Suspense fallback={<div>加载中...</div>}>
<RemoteButton />
</Suspense>
);
}
export default App;
注意，远程模块的引用路径remoteApp/Button并不是一个物理路径，而是Webpack在构建时根据remotes配置生成的虚拟标识。编译器会把它转换成运行时对远程容器加载函数的调用，这一过程对开发者完全透明。
共享依赖的版本协商与贪婪加载策略
模块联邦虽然带来了巨大的灵活性，但共享依赖的版本管理是一个关键问题。如果宿主应用和远程应用都使用React，但版本不同，页面中可能出现两个React副本，导致Hooks状态异常或体积膨胀。shared字段中的singleton选项可以强制只有一个React实例，Webpack运行时会优先复用宿主应用已经加载的版本。如果版本不匹配，会触发版本协商机制，通常以宿主应用的版本为准，远程应用会收到相应的警告。
贪婪一词在这里也体现在共享依赖的加载行为上。当远程模块被加载时，Webpack会检查共享依赖是否已经存在于全局作用域。如果存在且版本兼容，则直接使用；如果不存在或版本不兼容，就根据配置决定是否降级加载远程容器内自带的依赖副本。这种策略在保证运行效率的同时，也让多个应用共享一份基础库成为可能。但在实际项目中，需要仔细设计shared字段，将体积较大且要求单例的库（如React、React DOM、Vue等）设置为singleton，避免不必要的重复代码。
此外，模块联邦还支持动态远程容器，即remotes的地址不必在构建时写死。可以通过在运行时设置window.remoteUrl等方式，让入口文件地址可配置。这为多环境部署提供了方便，也符合微前端架构中动态编排容器的趋势。不过动态配置要处理好加载时机和错误兜底，比如远程入口加载失败时给出友好的降级方案。
实战中的性能考量与边界问题
模块联邦的按需加载机制会引入额外的网络请求，远程模块及其依赖只有在真正被使用时才会下载。这对于首屏性能有一定影响，但可以通过预加载策略进行优化。Webpack 5允许在配置中设置remotes的预加载选项，例如在空闲时预取远程入口文件，或者在浏览器空闲时预加载高频模块。合理的预加载能显著降低用户感知的延迟。
另一个需要注意的边界是样式隔离。模块联邦本身不处理CSS作用域隔离，如果远程模块带有样式文件，加载后会直接插入到主文档中，可能与宿主应用的样式冲突。常见的做法是使用CSS Modules、Shadow DOM或统一的样式命名规范。此外，远程模块的错误处理也容易被忽略，动态import的拒绝需要被捕获，避免整个应用崩溃。建议在lazy外层包装错误边界组件，对加载失败进行提示或重试。
整体来看，模块联邦这套贪婪宇宙式的能力并非所有项目都适用。对于小型单页应用，它可能带来不必要的复杂性；而对于多团队协作的大型平台，它能够显著提升开发效率和独立部署能力。在决定采用之前，需要评估团队对运行时共享、版本协商和网络失败处理的掌控程度。