Webpack 5 引入的模块联邦（Module Federation）已经广为人知，但在其生态演进中，社区把多应用间动态共享模块所构成的复杂依赖拓扑称为 Risking Universe，也就是冒险宇宙。它并不是官方文档里的一个独立配置项，而是当多个远程容器互相引用、版本浮动、运行时协商共存时自然形成的一种架构形态。在这种形态下，每个独立部署的前端工程都像一个宇宙中的星球，通过远程入口暴露或消费模块，稍有不慎就会因为版本错配引发运行时崩溃，因此才被叫做冒险宇宙。
冒险宇宙的形成原理与核心机制
要理解 Risking Universe，必须先看清模块联邦在 Webpack 5 中的底层运作方式。编译阶段，插件会把被标记为 exposes 的模块打包成独立的远程入口文件，并在主包中注入 __webpack_require__.f.remotes 等运行时函数。当代码执行到 import('app2/Button') 这类远程导入时，加载器会先去获取对方提供的 remoteEntry.js，从中读取其所暴露模块的映射表，再按需请求具体 chunk。多个应用彼此暴露和消费，就织成了一张跨工程的模块网，这便是冒险宇宙的物理基础。
在这张网里，最关键的 stabilizing 因素是 shared 配置。通过在宿主与远程侧都声明同一依赖（例如 React），并设定 singleton: true，Webpack 运行时会在 __webpack_share_scopes__ 中做版本协商。若已加载的 React 版本满足对方要求，则直接复用；若不满足且允许降级，则并行加载另一份。这种协商若缺乏统一规划，在三个以上应用互引时极易出现多实例或初始化竞态，这正是冒险宇宙让人头疼的地方。
下面是一段典型的宿主端配置，展示了如何把应用放入冒险宇宙并声明共享依赖：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host_app',
remotes: {
app2: 'app2@https://app2.ipipp.com/remoteEntry.js'
},
shared: {
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true, requiredVersion: '^18.0.0' }
}
})
]
};
多容器互引时的版本冲突与兜底策略
当冒险宇宙扩展到四个以上前端项目时，版本管理的复杂度会陡然上升。假设应用 A 依赖应用 B 的组件，B 又反向消费 A 的工具函数，同时 C 和 D 也介入这张网。如果某次发版 B 把 React 升到 19 而 A 仍是 18，且双方都设了 singleton，运行时会尝试让先加载的一方胜出，后加载方若不匹配就会抛错。这种循环引用加版本漂移，是冒险宇宙最常见的翻车点。
解决思路之一是在共享配置中显式写死 requiredVersion 并配合 eager: false，让加载顺序可控。另一思路是引入一个中立的基线容器（base universe），只承担纯工具与框架 singleton，业务容器全部只连它，不互相直连，从而把网状结构降维成星型。下面代码演示了在远程侧如何设置严格的共享边界，避免被宿主强行覆盖：
new ModuleFederationPlugin({
name: 'app2',
exposes: { './Button': './src/Button.js' },
shared: {
react: {
singleton: true,
requiredVersion: '^18.2.0',
import: 'react',
shareKey: 'react',
shareScope: 'default'
}
}
});
除了配置层面，运行时兜底也必不可少。可以在动态导入处包裹错误捕获，当远程容器不可达时渲染本地降级组件。由于冒险宇宙强调运行时组合，任何网络分区都可能让某颗星球失联，提前写好 fallback 才能不让整页白屏。这种容错思维应当写进每个参与方的基类里，而不是事后补救。
从构建产物看冒险宇宙对发版流程的影响
传统多页应用每次迭代都要把 vue 或 react 等公共库重新打出一份，用户访问不同子站重复下载。进入冒险宇宙后，只要各站约定同一 shared 作用域，公共库只需在首个站点加载，其余站点运行时复用。从构建产物分析，远程入口通常只有几 KB 的映射与启动逻辑，真实业务 chunk 才按需拉取，这显著降低了后续访问的带宽成本。
但这也改变了发版纪律。因为模块是运行时拼装，某个远程容器悄悄改了导出函数的签名，宿主并不会在编译期报错，只有用户点到对应功能才暴露问题。因此团队需要建立契约测试：在 CI 中对 exposes 的模块跑类型与接口断言，并把 remoteEntry 的哈希落库比对。下表列出了传统打包与冒险宇宙模式在发版环节的差别：
| 维度 | 传统多包 | 冒险宇宙 |
|---|---|---|
| 公共库加载 | 每站重复 | 首次后复用 |
| 接口变更感知 | 编译失败 | 运行时才知 |
| 发版耦合度 | 低 | 需契约约束 |
可以看到，冒险宇宙并非银弹，它把一部分集成风险从编译期转移到了运行期。只有配上共享版本治理与自动化契约校验，才能让这张动态模块网真正可控。对于已经采用微前端的企业，不妨把现有基座通信层下沉到 Webpack 5 原生远程容器，逐步把手工注册的星球纳入统一的冒险宇宙秩序中。