Hedge Universe 树篱宇宙并不是 Webpack 5 暴露给开发者的一行配置，而是一整套围绕模块联邦和持久化缓存成长起来的工程化范式。树篱代表模块之间的隔离边界，宇宙代表多个能够独立发布、独立回滚、独立扩缩容的应用容器。它的核心思路是让每个远程入口拥有自己的模块作用域，再通过 Webpack 5 内置的运行时共享机制完成安全通信。要实现这种结构，需要从构建配置、依赖策略和运行时调度三个层面同时下手，否则很容易做成一个只是拆了 chunk 的单体应用。
Hedge Universe 的核心机制：边界容器与运行时协商
传统微前端在做模块共享时，通常依赖全局变量或独立部署后通过 CDN 加载。这种方式在依赖版本不一致时会导致多个 React 实例同时存在，轻则状态异常，重则运行时直接崩溃。Hedge Universe 则利用 Webpack 5 的 ModuleFederationPlugin 在编译阶段生成容器描述，每个容器会明确声明自己暴露哪些模块、消费哪些远程入口以及共享哪些第三方依赖。这个声明不是简单的字符串列表，而是一份参与运行时协商的元数据。
下面是一个最基础的树篱宇宙配置，它定义了一个主容器 app_shell 和一个远程容器 catalog，并让两者共享 React 和 ReactDOM。
const { ModuleFederationPlugin } = require('webpack');
module.exports = {
entry: './src/index',
mode: 'development',
devServer: {
port: 3000,
},
plugins: [
new ModuleFederationPlugin({
name: 'app_shell',
filename: 'remoteEntry.js',
remotes: {
catalog: 'catalog@http://localhost:3001/remoteEntry.js',
},
exposes: {
'./Shell': './src/components/Shell',
},
shared: {
react: { singleton: true, requiredVersion: '^18.0.0' },
'react-dom': { singleton: true, requiredVersion: '^18.0.0' },
},
}),
],
};
这里 singleton: true 的作用并不是强制所有容器使用同一个实例，而是告诉 Webpack 在运行时优先复用已经存在的实例，只有当版本不满足 requiredVersion 时才回退到备用版本。这种协商机制和普通的模块缓存不同，它带有边界判断能力：主容器升级 React 到 18.3，远程容器声明需要 18.2，运行时仍可以让两个星球各自携带自己的 React，但不会互相覆盖全局对象。这种隔离性正是树篱宇宙与单体拆包最本质的区别。
如果把 app_shell 和 catalog 都挂载到同一个页面上，Webpack 会生成一个共享作用域对象，所有共享依赖通过这个对象进行版本对账。当使用者数量增多时，这种作用域会自然扩展成多维结构，类似宇宙中的引力网络，任何两个容器之间的依赖冲突都不会波及其它容器。
Hedge Universe 的配置落地与依赖边界策略
实际接入树篱宇宙时，最容易出现的错误是把 shared 配置分别写死在每个容器的 webpack 文件中。这样做短时间内能跑通，但随着容器数量增加，依赖版本会变得混乱不堪。例如主容器声明 axios 需要 1.4.0，某个远程容器却声明 1.6.0，两者都没有 singleton，结果同一个页面里会打包两份 axios，树篱边界退化成了普通 chunk 分割。更推荐的做法是将共享配置抽离成公共模块，每个容器只引用同一个对象。
const sharedConfig = {
react: { singleton: true, eager: false, requiredVersion: '^18.2.0' },
'react-dom': { singleton: true, eager: false, requiredVersion: '^18.2.0' },
axios: { singleton: false, requiredVersion: '^1.4.0' },
};
module.exports = sharedConfig;
另一个关键参数是 eager。当 shared 中的依赖被设置为 eager: true 时，模块会在容器初始化阶段直接执行，这适合需要在入口处立即渲染的 Shell 组件；但对于大多数业务依赖，建议保持 eager: false，让它们通过异步 chunk 按需加载，避免多个容器在同一时间初始化抢执行权。树篱宇宙的边界并不是越厚越好，太厚的边界会让首屏请求变得零散，太薄的边界又容易产生重复实例。通常只有 React、ReactDOM、路由库这类需要全局单例的依赖才设置 singleton: true。
在发布层面，每个远程容器建议配置 publicPath: 'auto'。这样无论容器被部署到 CDN、对象存储还是 Docker 集群内部，远程入口地址都能动态计算，减少因为构建环境不同导致的路由错误。同时要配合 Webpack 5 的 filesystem cache，把构建元数据持久化到磁盘。树篱宇宙之所以宽泛，是因为它把发布边界和缓存边界一并纳入了治理。
运行时通信与性能调优
远程容器的加载并不是通过浏览器的 ES Module 机制完成的，而是 Webpack 5 在运行时注入的模块系统扩展。每个容器初始化时会调用 webpack/runtime/remotes 逻辑，将远程入口挂载到本地模块表中。如果多个容器同时请求同一个远程模块，Webpack 会先检查该模块是否已经进入共享缓存，命中缓存后不会重复发起网络请求。这个细节在树篱宇宙模式下尤为重要，因为一个页面上可能同时挂载五个以上的远程容器，远程模块的重复加载会直接拖垮首屏性能。
import('catalog/ProductList')
.then(function (module) {
const ProductList = module.default;
const list = new ProductList({ page: 1 });
list.render();
})
.catch(function (err) {
console.error('远程容器加载失败:', err);
});
上面的动态加载方式在路由组件中非常常见。借助 React.lazy 或 Vue 的异步组件，可以在用户真正访问某个业务域时才去拉取对应远程容器。这样可以避免 Webpack 在初始化阶段预先加载所有远程入口，减少首屏的脚本解析压力。需要注意的是，做按需加载时不要把所有远程容器都写在 remotes 的静态声明里，虽然 Webpack 允许这样配置，但它会让构建器在启动阶段就建立完整的远程模块依赖图，产生大量无用请求。
性能调优的另一个重点是缓存分区。Webpack 5 的持久化缓存默认会把容器元数据和模块转换结果写入文件系统，如果多个容器的缓存目录混用，会出现缓存穿透或脏数据。建议为每个容器设置独立的 cache.name，并通过 output.path 将缓存文件与构建产物分开存放。这样当某个远程容器单独升级时，其它容器的缓存仍然有效，整体构建时间可以缩短到一次增量编译的水平。
常见误区与适用边界
第一个常见误区是把 Hedge Universe 当成模块共享的银弹。如果项目只有两三个页面，或者所有模块都由同一个团队发布，引入树篱宇宙反而会增加运维复杂度。模块联邦的收益来自于发布解耦和多团队并行演进，而不是单纯为了代码复用。对于小型项目，直接使用原生 ES Modules 或轻量级微前端框架即可，不需要为了架构而架构。
第二个误区是过度共享。不少团队一上来就把所有 npm 依赖都塞进 shared，结果运行时协商过程变长，甚至出现版本风暴。需要明确的是，只有会跨容器共享且需要单例的依赖才适合放入 shared。例如 lodash 这类工具库通常是各容器独立打包更合适，因为每份副本体积不大，而且不同容器对版本的要求差异很小，共享反而会放大协商失败和回退加载的风险。可以通过 webpack-bundle-analyzer 观察远程容器之间的模块重复度，超过 20% 再考虑加入 shared，未超过则维持独立打包。
从系统设计角度看，Hedge Universe 树篱宇宙真正解决的是前端架构中的发布耦合问题。它把 Webpack 5 的模块系统从单应用内部提升到分布式应用集群，通过边界描述、运行时协商和持久化缓存三个支柱，让多个独立发布的容器能够在同一个页面中安全共存。如果团队正面临多应用协同发布、依赖版本冲突、构建缓存分散等痛点，可以先在一个非核心业务模块上验证这套模式，再逐步推广到整个应用集群。