Webpack 5 引入了一个被社区戏称为“Ruling Universe”的能力，指的就是模块联邦（Module Federation）。虽然官方从未使用过这个名称，但它带来的改变确实让多个前端应用之间的关系从“各自为战”变成了可以互相“统治”对方模块的灵活协作。模块联邦允许一个构建产物在运行时从另一个构建产物中动态加载模块，而不需要把这些模块事先打包进自己的代码，也不需要重新发布npm包。本文会深入它的容器模型、暴露与消费机制、共享依赖策略，并通过两个独立应用演示远程组件加载，最后对比微前端方案给出实践建议。
一、为什么模块联邦被称为“统治宇宙”级特性？
在模块联邦出现之前，前端团队之间共享代码或组件通常有三种方式。第一种是发布npm包：远程团队把组件发布到私有仓库，消费方安装后重新构建。这种方式的问题在于发布链路长、版本管理复杂，每次组件更新都要走完整的发布和构建流程，而且多个应用之间很容易出现依赖重复打包。第二种是使用iframe：虽然隔离彻底，但页面之间的通信、路由同步、样式统一都成了麻烦事，用户体验也大打折扣。第三种是基于single-spa或qiankun这类微前端框架，通过注册子应用来加载，但这类方案通常需要统一的框架底座、约定生命周期，上手成本和维护成本都不低。
模块联邦的突破点在于它把“共享模块”这件事从构建期搬到了运行时。远程应用暴露出来的组件或函数，消费方可以直接通过动态import语法加载，就像加载本地异步模块一样自然。更关键的是依赖共享机制：如果远程模块和消费方都依赖React，模块联邦可以保证整个页面只加载一份React实例，避免多版本冲突。这种能力让多个完全独立部署的应用在浏览器里呈现出“一个整体”的体验，确实有几分掌控全局的“统治宇宙”意味。
不过需要说明的是，“Ruling Universe”并不是Webpack官方文档里的正式术语，它更像社区为了突出模块联邦强大能力而起的绰号。真正要掌握的是模块联邦背后的容器技术，理解了容器的工作方式，才能在不同场景下灵活运用它。
二、核心概念：容器、暴露与消费
模块联邦的核心抽象是“容器”（Container）。可以把容器理解成一个运行时遥控器，它记录了一个构建产物向外暴露了哪些模块，以及这些模块依赖了哪些共享包。Webpack在打包时如果检测到配置文件中的ModuleFederationPlugin，就会额外生成一个远程入口文件，默认命名为remoteEntry.js。这个文件的体积很小，主要作用是在浏览器中加载远程模块的代码块，并管理共享依赖的作用域。
“暴露”（expose）是指远程应用把本地模块声明为可被其他应用消费的接口。例如一个组件库应用可以暴露./Button、./Modal等路径，消费方只要在配置中声明对远程容器的引用，就可以通过类似import('remoteApp/Button')的语法获取组件。这里的remoteApp是消费方给远程容器起的名称，它对应一个真实的远程入口地址。这种映射关系在构建时由remotes字段定义，但在运行时才真正发起网络请求加载远程代码。
“消费”（consume）的过程对业务代码来说几乎透明。消费方不需要关心远程模块的内部实现，也不需要在本地安装远程应用的依赖。真正要处理的是异步加载状态：因为远程模块需要从网络获取，所以通常要配合React.lazy、Suspense或Vue的异步组件机制来展示加载中的占位内容。这种异步性也意味着远程模块的加载失败不会阻塞整个应用渲染，可以把错误边界做好来提升健壮性。
三、实战：两个独立应用远程加载组件
假设有远程应用remoteApp暴露一个按钮组件，消费方hostApp在页面中动态加载它。两个应用各自独立构建、独立部署，唯一联系是远程应用会提供一个remoteEntry.js入口文件。远程应用的项目结构可以是普通的React项目，在webpack.config.js中做如下配置：
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
entry: './src/index.js',
mode: 'development',
devServer: { port: 3001 },
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button.jsx',
},
shared: {
react: { singleton: true, eager: true },
'react-dom': { singleton: true, eager: true },
},
}),
new HtmlWebpackPlugin({ template: './public/index.html' }),
],
};
消费方hostApp的配置重点在remotes字段。它声明了一个名为remoteApp的远程容器，并把该名称与远程入口文件地址关联起来。消费方同样使用ModuleFederationPlugin，配置如下：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
entry: './src/index.js',
mode: 'development',
devServer: { port: 3002 },
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js',
},
shared: {
react: { singleton: true, eager: true },
'react-dom': { singleton: true, eager: true },
},
}),
],
};
远程组件本身只是一个普通的React函数组件，不需要任何特殊封装。示例中的Button.jsx内容如下：
import React from 'react';
export default function Button({ label = '来自远程的按钮' }) {
return <button>{label}</button>;
}
在消费方代码中，需要通过动态import加载远程组件，并使用React.lazy包装。注意这里的导入路径是remoteApp/Button，而不是本地相对路径。完整示例如下：
import React from 'react';
const RemoteButton = React.lazy(() => import('remoteApp/Button'));
function App() {
return (
<div>
<h1>Host 应用</h1>
<React.Suspense fallback="加载远程组件...">
<RemoteButton />
</React.Suspense>
</div>
);
}
export default App;
运行两个服务后，访问消费方页面，浏览器会从http://localhost:3001/remoteEntry.js加载远程容器，再按需加载按钮组件对应的JavaScript chunk。整个过程中，消费方的初始bundle不会包含远程组件代码，而是等实际需要时才去获取，这大幅降低了应用首屏包的体积。
四、共享依赖与版本控制策略
模块联邦最容易被误解的部分是shared配置。很多开发者认为只要把依赖写进shared，Webpack就会自动去重。实际上，shared要做的事情是声明哪些包是“共享作用域”的一部分，并决定当版本不一致时如何选择。以React为例，如果远程应用和消费方都声明react为共享依赖，并且都满足版本范围，那么运行时只会加载一份React。这样既避免了重复打包，也保证了React内部状态（如hooks）不会因为多实例而出现异常。
当版本不匹配时，情况会复杂一些。假设消费方依赖React 16，远程应用使用React 17，而两者都不满足对方声明的requiredVersion，Webpack会降级为分别加载各自的React实例。这种降级行为保证了功能可用，但可能导致两个React实例之间的组件嵌套出现问题，比如无法共享Context或触发不兼容警告。因此在实际项目中，最好在团队之间约定统一的React主版本，并在shared中显式设置singleton: true和合理的requiredVersion。
除了单例化，eager属性也值得注意。对于remoteApp来说，如果eager: false，远程应用在加载自己入口时会异步获取共享依赖，从而减少首屏阻塞；而eager: true则让远程应用立即初始化共享依赖，方便消费方在同步代码中使用。对于消费方hostApp，通常建议对核心依赖设置eager: true，因为消费方本身就是页面入口，提前初始化共享作用域能避免后续远程模块加载时出现时序问题。
五、与主流微前端方案对比及适用边界
如果将模块联邦与qiankun、single-spa、iframe等方案放在一起比较，最明显的差异在于模块联邦解决的是“代码共享”问题，而传统微前端大多解决的是“应用整合”问题。qiankun通过JS沙箱和样式隔离加载完整子应用，适合把一个大型后台系统拆成多个可由不同团队独立开发部署的子应用；但子应用之间共享组件仍然要借助npm包或全局变量。模块联邦则更细粒度，可以让一个子应用直接使用另一个子应用的某个组件或工具函数，而无需加载整个子应用壳。
但模块联邦也不是万能的。它要求所有参与方都使用Webpack 5构建，这限制了技术栈统一性。如果团队中还有Vite、Rollup或旧版Webpack项目，需要额外的适配层或迁移成本。另外，模块联邦默认不提供样式隔离，远程组件的CSS会直接注入消费方页面，容易造成类名冲突，需要借助CSS Modules、CSS-in-JS或约定前缀来解决。还有一点是运行时错误处理：远程模块加载失败、网络波动、远程入口文件不可用等都需要消费方自己设计错误边界和重试逻辑。
从实践角度看，模块联邦特别适合那些已经统一到React或Vue技术栈、有多个独立部署的前端应用、又希望共享组件或业务逻辑的团队。例如一个电商中台包含商品管理、订单管理、用户管理等子系统，每个子系统由一个小组负责开发部署，但都希望复用统一的表格组件、权限校验函数和API请求层。这时不必把所有公共代码发成npm包再等各小组升级，而是由公共组件应用通过模块联邦暴露这些能力，其他应用在运行时动态消费。这种方式能显著降低跨团队协作的沟通成本和发布频率。
需要提醒的是，模块联邦虽然强大，但不要把远程模块当作“随意跨应用调用任意内部逻辑”的工具。过度暴露模块会增加远程接口的耦合度，导致应用之间边界模糊。建议每个远程应用只暴露少数经过抽象、稳定、有明确职责的公共模块，而不是把所有组件都开放出去。同时要对远程入口文件做长期缓存或CDN加速，因为每次加载远程模块都会请求这个文件，其可用性直接影响整个页面的稳定性。
总结来说，Webpack 5 的模块联邦确实担得起“Ruling Universe”这个戏称。它改变了多个前端应用之间共享代码的方式，让独立构建与运行时协作得以并存。理解了容器、暴露、消费和共享依赖这四个核心概念，就能在合适的场景中发挥它最大的价值，同时避开常见的版本冲突和样式隔离等坑。