Alienating Universe（疏远宇宙）在 Webpack 5 语境中并不是官方文档里的正式概念，而是开发者对模块联邦（Module Federation）在共享依赖处理不当时形成运行时隔离现象的一种形象叫法。简单来说，当宿主应用和远程应用各自使用了自己的 React 或 Vue 实例，或者同一个库被加载了两份，它们就像处在互不相通的平行宇宙里，状态、上下文和单例全部割裂。要理解这个现象，必须从 Webpack 5 引入的 ModuleFederationPlugin 容器机制说起。容器为每个构建产物提供独立的模块作用域，远程模块加载后，如果依赖没有被正确提升到统一作用域，就会出现多个宇宙并存的问题。
疏远宇宙的技术根源：模块容器的隔离边界
Webpack 5 的模块联邦允许一个应用在运行时动态加载另一个应用暴露的模块，这个能力依赖每个构建生成的容器入口文件。容器本质上是一个经过特殊包装的模块映射表，它知道如何加载远程模块以及从哪个共享作用域中获取依赖。但容器默认并不会自动把所有依赖都提升到全局，而是优先在自身的作用域中查找依赖。这样一来，如果远程应用在打包时没有把 react 或 react-dom 标记为共享依赖，而是直接打进自己的 bundle，宿主和远程就会各自持有一份独立实例。
这种隔离并非完全坏事。隔离可以避免远程模块与宿主应用之间产生不必要的类型冲突，也能让远程应用具备独立升级的能力。但问题在于，很多状态管理库、UI 框架和上下文对象都依赖单例语义。例如 React 的 Context API 只有在同一个 React 实例下才能正常工作，如果页面中存在两个 React 实例，跨组件传递的上下文就会断裂，hooks 状态也不会同步。这正是疏远宇宙最典型的症状。
下面的配置展示了一个最简单的模块联邦宿主应用。注意 shared 字段虽然写了 react 和 react-dom，但如果没有进一步约束，Webpack 仍然可能因为版本不匹配而加载多个实例。
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');
module.exports = {
entry: './src/index',
mode: 'development',
devServer: { port: 3000 },
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js'
},
shared: {
react: { singleton: true, requiredVersion: '^18.2.0' },
'react-dom': { singleton: true, requiredVersion: '^18.2.0' }
}
})
]
};
共享依赖配置：singleton 与 requiredVersion 如何决定宇宙是否重叠
要打破疏远宇宙，关键在于 shared 配置的精确性。singleton 选项告诉 Webpack 在运行时只允许一个实例存在。它通过全局共享作用域中的版本检查来实现：当宿主和远程都声明了同一个 singleton 依赖时，Webpack 会比较双方声明的版本范围。如果版本兼容，就共用同一个实例；如果不兼容，Webpack 会回退为加载多份实例，并在控制台打印警告。很多开发者误以为只要写了 singleton 就能强制单例，实际上如果宿主使用 React 18，远程使用 React 17，这两个版本不可能共用同一个实例，疏远宇宙依然存在。
requiredVersion 用来声明当前应用期望的依赖版本范围。它不会强制远程模块使用该版本，而是告诉 Webpack 在共享作用域中应该提供哪个版本。strictVersion 则更加严格，当设置为 true 时，如果远程声明的版本与宿主提供的版本不兼容，Webpack 会直接报错而不是静默降级。这种严格模式适合在团队内部统一依赖版本的场景，可以尽早暴露版本冲突，避免生产环境中出现难以排查的隔离问题。
shared: {
react: {
singleton: true,
requiredVersion: '^18.2.0',
strictVersion: false,
eager: false
},
lodash: {
singleton: false,
requiredVersion: '^4.17.21'
}
}
还有一点容易被忽视，即共享作用域的名称。shareScope 默认是 default，如果不同的模块联邦容器使用了不同的 shareScope，它们之间就完全不会共享任何依赖。这相当于人为制造了多个宇宙。在大型微前端架构中，建议所有容器显式指定同一个 shareScope，例如 shareScope: 'main-scope'，确保远程模块和宿主应用查找依赖时使用同一张映射表。
持久化缓存与产物隔离：另一个被忽视的疏远因素
Webpack 5 引入了 filesystem 持久化缓存，可以把模块构建结果缓存到磁盘，大幅缩短二次构建时间。但缓存与疏远宇宙也有间接关系。缓存通过 buildDependencies 和模块标识符来决定缓存是否有效，如果不同构建目录或 CI 环境中的绝对路径不一致，或者 cache.name 不同，模块标识就可能发生变化。虽然这不会直接产生多个 React 实例，但会导致不同机器上产出的容器入口文件内容不一致，增加远程模块加载失败的概率。
更隐蔽的场景是，如果宿主的缓存目录与远程应用的缓存目录同名但实际路径不同，Webpack 可能错误地复用一部分缓存模块，导致依赖解析结果与预期不一致。尤其在 monorepo 中，如果不同子项目共用一个缓存目录，而各自的依赖版本又不同，就可能在构建阶段产生交叉污染。这种污染会在运行时表现为依赖实例错乱，和疏远宇宙的症状非常相似。
const path = require('path');
module.exports = {
cache: {
type: 'filesystem',
name: 'webpack5-cache',
buildDependencies: {
config: [__filename]
},
cacheDirectory: path.resolve(__dirname, '.webpack-cache')
}
};
因此，在排查疏远宇宙问题时，不能只盯着 shared 配置，还要确认缓存策略是否合理。建议每个项目使用独立的 cacheDirectory，并且在 CI 中设置统一的路径前缀。如果项目使用 Docker 构建，可以把 .webpack-cache 挂载到固定目录，避免因为容器路径不同导致缓存失效或错用。
避免疏远宇宙的工程实践
要彻底消除疏远宇宙，第一步是统一依赖版本。在微前端项目中，宿主应用和远程应用应该尽量使用完全相同的 react、react-dom、vue 等核心框架版本，并且通过 package.json 的 lock 文件锁定具体版本。如果团队使用 monorepo，可以把核心依赖提升到根目录，通过 workspaces 统一管理，子项目只声明 peerDependencies，这能从根本上减少多版本共存的可能性。
第二步是精细配置 shared。对于需要单例的库，设置 singleton: true 和明确的 requiredVersion，并在 CI 中开启 strictVersion 检查。对于不需要单例的工具库，可以关闭 singleton，允许每个容器持有自己的副本，这样反而能降低共享作用域的复杂度。同时，所有容器必须使用相同的 shareScope，否则前面的配置都会失效。
第三步是建立监控手段。可以在应用启动时打印关键依赖的实例标识，例如在 React 中检查 React.version 是否一致，或者在 Vue 中检查全局 Vue 构造函数数量。如果发现多个版本，立即在开发阶段阻断发布。配合 webpack-bundle-analyzer 分析产物，可以直观地看到同一个库是否被打进多个 bundle。只有把配置、构建和运行时监控结合起来，才能让疏远宇宙彻底消失，让每个远程模块真正运行在同一个可靠的容器宇宙中。