在 Webpack 4 时代，所有模块最终都会被打进一个（或少数几个）bundle，整个应用可以理解为一个封闭的模块宇宙：入口、依赖、公共库全部在编译期确定，运行时没有太多协商余地。这种模型在单体应用里工作得很好，可一旦多个团队、多个应用希望共享组件和依赖，问题就来了——要么各自打包一份造成体积翻倍，要么依赖 externals 加 CDN 全局变量这种脆弱方案。Webpack 5 提出的 Separating Universe（分离宇宙）理念，正是为了解决这个边界问题：它允许一个模块宇宙在运行时被拆开，由多个独立构建各自持有一部分，再通过 Module Federation（模块联邦）机制互相访问。
什么是 Separating Universe：从封闭构建到开放运行时
所谓宇宙（Universe），在 Webpack 作者 Tobias Koppers 的语境里指的是一次编译所覆盖的全部模块集合。传统模式下，每个应用是一个独立宇宙，宇宙之间没有任何通信协议，只能靠构建期的 npm 依赖或运行期的全局变量交换代码。这种方式的问题在于：共享必须发生在构建之前，运行时无法感知对方的存在。
Separating Universe 的核心思想是把这堵墙打开：两个独立编译的应用，可以在浏览器运行时动态地引用对方暴露的模块，同时协商出共同依赖（比如 React）应该用谁的副本。实现这一目标的载体就是 Module Federation 插件。每个参与方可以扮演两种角色：host（消费方）负责加载别人的模块，remote（提供方）通过 exposes 把自己宇宙中的模块暴露出去。同一个应用可以同时是 host 和 remote。
这个设计的巧妙之处在于，它并没有引入全新的运行时机制，而是复用并增强了 Webpack 原有的异步 chunk 加载能力。remote 暴露的模块在 host 看来就像一个异步 chunk，只是加载地址从本地构建产物指向了另一个应用的运行时入口。
模块联邦的配置方式与运行原理
先看一个最小可用的配置。假设有两个应用：app1 是宿主，app2 是远程提供方，app2 暴露一个 Button 组件。
// app2 的 webpack.config.js（作为 remote）
const { ModuleFederationPlugin } = require("webpack").container;
module.exports = {
// 必须指定 output.publicPath，让 host 知道从哪里加载远程 chunk
output: {
publicPath: "http://localhost:3002/",
},
plugins: [
new ModuleFederationPlugin({
name: "app2",
filename: "remoteEntry.js",
exposes: {
"./Button": "./src/Button.jsx",
},
shared: {
react: { singleton: true },
"react-dom": { singleton: true },
},
}),
],
};
// app1 的 webpack.config.js（作为 host）
const { ModuleFederationPlugin } = require("webpack").container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: "app1",
remotes: {
app2: "app2@http://localhost:3002/remoteEntry.js",
},
shared: {
react: { singleton: true },
"react-dom": { singleton: true },
},
}),
],
};
host 侧消费远程模块时，写法与普通动态导入几乎一致：
// app1/src/App.jsx
const RemoteButton = React.lazy(() => import("app2/Button"));
function App() {
return (
<React.Suspense fallback={<div>加载中</div>}>
<RemoteButton />
</React.Suspense>
);
}
运行时的流程大致分为四步。第一，host 加载 remote 的 remoteEntry.js，这个文件里包含 remote 的容器（container）代码。第二，host 调用容器的 init 方法，完成共享依赖的版本协商。第三，协商通过后，host 通过容器的 get 方法拿到目标模块的工厂函数。第四，模块对应的 chunk 被异步下载并执行，最终注入到 host 的模块缓存中。整个过程都建立在 Promise 之上，因此天然支持代码分割和懒加载。
其中 shared 配置是最容易被忽视但最关键的一环。两个应用都声明了 react 为共享依赖后，先加载的一方会把自己的 React 实例注册到一个全局共享作用域，后加载的一方发现已有可用版本就不再下载自己的副本。singleton 设为 true 则强制全局只保留一个实例，这对 React 这类依赖单一实例的库是必须的，否则会出现著名的多实例 Hook 报错。
与 npm 共享、externals、Monorepo 方案的对比
在模块联邦出现之前，跨应用共享代码主要有三条路，各有明显短板：
- npm 包共享：各应用安装同一个组件库。问题在于版本锁定在构建期，A 应用升级后 B 应用不升，长期版本漂移；共享库更新需要每个应用重新构建发布。
- externals 加全局变量：把 React 之类的外链到 CDN。运行时确实只有一份，但 externals 声明的是具体全局变量名，依赖关系脆弱，且只能整库共享，无法按模块粒度拆分。
- Monorepo 统一构建：把所有应用收进一个仓库统一编译。共享没问题了，但构建时间随规模线性增长，发布互相牵连，一个团队的改动可能阻塞所有人。
模块联邦的差异在于共享发生在运行时且粒度是模块级别。remote 暴露的 Button 更新后，host 无需重新构建，下次加载时拉到的就是新版本（可通过 remoteEntry 的缓存策略控制）。同时 shared 机制保证了关键依赖的单一实例，避免了 externals 方案的手工维护成本。可以说它是第一个把跨构建模块共享做成一等公民的前端构建方案。
当然它也不是银弹。模块联邦引入了运行时依赖，host 与 remote 之间的接口契约不再由 TypeScript 编译期保证，需要靠约定或额外的类型生成工具弥补；shared 依赖版本不一致时的协商结果也可能不符合预期，建议对核心库始终加 requiredVersion 和 singleton 双重约束。
落地微前端架构时的注意事项
模块联邦目前最主要的应用场景是微前端。把大型平台按业务域拆成多个独立部署的子应用，主应用作为 host 动态装配。落地时有几个高频坑值得提前了解。
第一是 remoteEntry 的缓存策略。remoteEntry.js 类似 manifest，建议设置较短的缓存时间或使用带 hash 的文件名加不缓存的入口引用，否则 remote 更新后 host 可能拿到旧的容器代码。第二是路由集成：远程应用暴露的往往不只是组件还有路由片段，host 需要在自己的路由表中为远程模块预留位置，并处理好 Suspense 边界与错误兜底，避免一个 remote 挂掉拖垮整个页面。第三是样式隔离与 CSS 顺序，模块联邦本身不做样式隔离， scoped 方案或 CSS Modules 需要自行设计。
第四是开发体验问题。本地开发时 host 想加载本地正在修改的 remote，可以把 remotes 地址指向本地 dev server；反过来联调多个 remote 时，配合 Vite 风格的代理或使用 @module-federation/enhanced 提供的开发工具可以显著减少切换成本。此外，如果团队对类型安全要求高，可以关注基于模块联邦的类型生成方案，让 remote 在构建时导出 d.ts，host 端消费时仍然保留编译期检查。
总结来看，Separating Universe 不只是一个新特性，而是一种构建边界的重新划分：构建期各自独立，运行时按需融合。如果你的系统正被体积、发布耦合或多团队协作拖累，模块联邦值得认真评估；如果只是普通单体应用，则不必为了用而用，保持简单的单宇宙构建反而是更稳妥的选择。
Webpack 5Module Federation微前端修改时间：2026-09-10 09:55:16