Webpack 5 引入的容器与模块联邦能力，让构建产物在运行时可以灵活共享依赖。当多个远程应用和宿主页面都使用同一个包时，打包器不再需要把公共依赖重复打进每个 chunk，而是通过共享作用域把符合版本范围的模块实例复用起来。但如果宿主要求 React 17，而某个远程模块要求 React 18，两个版本如果被强行合并到同一个作用域，全局 API 和 hooks 状态就可能串扰。Equilibrating Universe 平衡宇宙就是在这种场景下用来描述不同版本模块如何被分配到彼此隔离的运行时区域，同时维持一份可预测的协商顺序。

平衡宇宙并不是 Webpack 5 官方文档中一个独立命名的开关，而是对 shared scope 与容器交互方式的形象概括。它的核心思想是：每一个依赖包的主版本都可以拥有一个运行时作用域，像平行宇宙一样互不干扰；当依赖请求发生时，加载器根据版本范围尝试在已有宇宙中寻找可复用实例，只有找不到匹配版本时才创建新的宇宙。这样既避免了无脑单例带来的升级锁死，也防止了多版本全局变量互相覆盖的问题。

一、平衡宇宙要解决的问题与作用域模型

传统 Webpack 处理多版本依赖时，往往会把同一个包的两个版本全部打入产物。如果两个入口模块分别依赖 lodash 3 和 lodash 4，最终生成的代码中会同时存在两份 lodash 副本。对于纯函数工具库来说，这通常只会增加体积；但对于带有全局状态或原生对象扩展的库，两个版本同时运行就可能发生难以追踪的 bug，例如某个版本修改了 Array.prototype，另一个版本却认为原型未被修改。

平衡宇宙的作用域模型把 shared scope 设计成一个多层次的容器。每个依赖名对应一个共享组，共享组内部按版本号或来源划分出不同的实例。宿主与远程模块在初始化时都会把自己的依赖注册到 shared scope 中，注册信息包括版本、来源、获取函数以及是否 eager 加载。后续任何一方请求该依赖时，都会先从共享组中查找满足 semver 范围的实例，而不是直接创建新副本。

// 运行时共享作用域伪结构
const sharedScope = {
  lodash: {
    "4.17.21": {
      get: () => Promise.resolve(() => require("lodash")),
      from: "host",
      eager: false
    },
    "3.10.1": {
      get: () => Promise.resolve(() => require("lodash")),
      from: "remote-legacy",
      eager: true
    }
  }
};

这种设计的好处是兼容版本可以合并成一个实例，减少重复执行副作用的机会；而完全不兼容的版本则被放在隔离的宇宙中，避免相互污染。对于 React、Vue 这类需要保持全局唯一实例的框架，我们会倾向于把兼容版本收敛到同一个共享实例；对于 lodash 这类无状态工具库，则可以放宽版本范围，让不同主版本并行存在。

二、通过 ModuleFederationPlugin 配置平衡宇宙

在 Webpack 5 的实际配置中，平衡宇宙的行为主要由 ModuleFederationPlugin 的 shared 字段决定。关键参数有三个：singleton 表示该依赖在全局是否只允许一个实例；requiredVersion 声明当前应用期望的版本范围；eager 控制该共享依赖是否在容器初始化时立即加载，而不是等到第一次 import 时才加载。

以微前端宿主应用为例，假设宿主使用 React 18，并且希望所有远程模块都复用同一个 React 实例，那么可以把 React 配置为 singleton，同时指定较宽的版本范围。对于 lodash 这种允许并行多版本的库，则可以把 singleton 设置为 false，让远程模块在版本不匹配时加载自己的副本。这样既保证了全局框架状态的一致性，又不强制所有团队升级工具库版本。

const { ModuleFederationPlugin } = require("webpack").container;
module.exports = {
  entry: "./src/index",
  mode: "development",
  devServer: {
    port: 3000
  },
  plugins: [
    new ModuleFederationPlugin({
      name: "host_app",
      remotes: {
        legacy_remote: "legacy_remote@http://localhost:3001/remoteEntry.js",
        modern_remote: "modern_remote@http://localhost:3002/remoteEntry.js"
      },
      shared: {
        react: {
          singleton: true,
          requiredVersion: "^18.2.0",
          eager: true
        },
        lodash: {
          singleton: false,
          requiredVersion: "^4.0.0",
          eager: false
        },
        "legacy-utils": {
          singleton: false,
          requiredVersion: "^2.0.0",
          eager: false
        }
      }
    })
  ]
};

这里有一个容易混淆的点：singleton: true 并不等于自动统一版本。如果宿主和远程模块声明的 requiredVersion 范围没有交集，Webpack 5 会优先保留已经加载的实例，并在控制台输出版本冲突警告。这时远程模块可能会在错误的 React 版本上运行，从而触发 hooks 调用顺序异常等问题。因此，团队在声明 singleton 依赖时，必须提前约定主版本范围，让 semver 匹配存在交集。

三、运行时加载顺序与回退机制

远程模块的入口文件在加载后会先执行共享作用域初始化，把自己的依赖版本注册进去。随后当宿主或远程任意一方发起 import 请求时，Webpack 的容器运行时会在 shared scope 中查找满足条件的实例。匹配过程会综合比较版本号、来源优先级和 eager 状态。如果找到多个候选版本，通常选择最接近 requiredVersion 的一个；如果没有任何候选版本满足范围，则触发回退逻辑。

回退行为取决于 singleton 配置。对于 singleton 为 false 的依赖，加载器会创建一个新的隔离实例并把该版本注册到共享组中。对于 singleton 为 true 的依赖，加载器仍然只保留一个实例，新请求只能得到旧实例或抛出错误。这种机制意味着平衡宇宙不能凭空消除多版本，它只是用运行时的空间换取了状态隔离，并尽量减少不必要地重复执行模块初始化代码。

// legacy_remote 中的应用入口
import { render } from "react";
import { groupBy } from "lodash";
export async function mountLegacy(container) {
  const React = await import("react");
  const _ = await import("lodash");
  const element = React.createElement("div", null, "legacy remote");
  container.appendChild(element);
  return Promise.resolve();
}

从包体积角度看，如果远程模块的 lodash 版本无法与宿主共享，最终产物中仍然会加载两份 lodash。平衡宇宙的优势主要体现在运行时行为上：两份 lodash 不会尝试接管同一个全局变量，也不会因为某个版本修改了原生对象而影响另一个版本。对于需要严格隔离的场景，这是一种成本可控且可预测的方案。

四、多团队协作中的平衡宇宙治理建议

在真实的微前端项目中，依赖治理往往比技术实现更复杂。一个常见误区是把所有公共依赖都设置成 singleton，试图通过强制统一版本消除重复加载。这样做虽然可以减少运行时实例数量，但会让远程模块升级变得非常困难：只要有一个团队没有跟上主版本，其他团队就必须等待，升级节奏被最慢的模块卡住。

更好的策略是按照依赖的全局副作用强弱来分类。像 React、React DOM、Vue 这类存在全局 hook 状态、上下文对象或指令注册的库，应当尽量保持 singleton，并约定主版本一致。像 lodash、date-fns、axios 这类无全局副作用或副作用较小的库，可以允许多版本并行。样式类依赖则需要结合 sideEffects 配置，避免同一样式文件被多次注入。

此外，建议在 CI 环节增加依赖版本一致性检查，例如扫描所有远程模块的 package.json，确认 singleton 依赖的主版本范围存在交集。对于版本范围声明过宽的情况，可以通过锁文件或 overrides 机制收紧。平衡宇宙的价值只有在这种治理策略下才能稳定发挥，否则运行时的协商逻辑会不断产生意外回退，最终让调试成本超过它带来的收益。