Webpack 5 提出的 Diversity 多元并非单纯指支持更多文件类型，而是围绕应用形态碎片化带来的构建隔离与运行时协作问题，给出了一套原生级的模块共享方案。最核心的体现是 Module Federation，它允许一个构建产物声明自己暴露的模块，也允许另一个构建在编译时把这些模块当作远程依赖。这种能力让前端团队可以在不合并代码仓库的前提下，复用彼此的组件与工具函数，从根本上改变了多包协同的开发模式。
编译期依赖图谱如何支撑多元构建
在 Webpack 4 及之前，如果项目 A 想用项目 B 的组件，通常要把 B 打包成库再通过 npm 安装，或者利用运行时动态脚本加载后再取全局变量。前者导致版本锁死与重复构建，后者缺乏类型与依赖分析。Webpack 5 的 Diversity 思路是在编译阶段就读取远程容器的暴露清单，把import('appB/Button')这样的语句映射到远程入口。这意味着依赖图谱不再局限于单一仓库，而是跨构建连通。
具体配置上，需要在插件中声明name与exposes。下面给出一个基础宿主端的配置片段，注意其中的remotes指向另一个构建生成的远程容器文件：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
appB: 'appB@https://cdn.ipipp.com/appB/remoteEntry.js'
},
shared: { react: { singleton: true }, 'react-dom': { singleton: true } }
})
]
};
上面的shared字段体现了 Diversity 的另一个要点：允许不同构建协商公共依赖。通过singleton标记，可以确保所有远程模块共用同一份 React 实例，避免多副本导致的上下文错乱。这种协商发生在编译期，但生效于运行时，是多元构建稳定性的关键。
运行时加载与隔离机制剖析
当浏览器真正执行import('appB/Button')时，Webpack 5 生成的运行时先检查本地是否已注册appB容器。如果没有，则按remotes里的 URL 拉取remoteEntry.js，该文件本身很小，只描述远程模块的位置与共享依赖信息。随后真正点击组件时才会按需加载对应 chunk。这种分层拉取减少了首屏压力，也契合 Diversity 强调的按需多元加载。
隔离方面，每个容器拥有独立的作用域，远程模块内部引用的依赖优先用自己的shared版本，若宿主提供了单例则切换。下面代码展示如何在远程端暴露模块，并限制自身依赖不向外渗透：
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'appB',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/Button.jsx'
},
shared: {
react: { singleton: true, import: false }
}
})
]
};
这里import: false表示 appB 不主动要求宿主提供 React，只声明自己需要单例。若宿主已加载则复用，否则自行打包。这种细粒度控制避免了强制耦合，也是 Diversity 多元特性在跨团队边界时的实用策略。但需注意，如果两边 React 大版本不一致且都设了单例，运行时会报错而非静默降级，因此协定版本区间必不可少。
缓存策略与常见落地误区
Diversity 带来的远程容器文件应被视为长期缓存的稳定入口。由于remoteEntry.js只包含模块映射，不包含业务代码，它的 hash 变化频率低，适合设较长 Cache-Control。真正的业务 chunk 则按内容哈希命名，利用 CDN 边缘缓存。这样多个宿主应用引用同一远程端时，浏览器只需下载一次公共 chunk，显著降低重复流量。
实践中最常见的误区是盲目把全部依赖放进shared。曾有团队把 lodash 整个包共享，结果远程端使用的深层子路径未被宿主预载，触发额外请求 waterfall。正确做法是用shareScope分组，或仅共享确为单例的框架级依赖。以下表格对比两种策略差异：
| 策略 | 优点 | 风险 |
|---|---|---|
| 全量共享 | 配置简单，依赖不重复 | 映射体积大，未用到的子模块也需协商 |
| 单例框架共享 | 运行时稳定，加载可控 | 业务库需各端自行打包，体积略增 |
另一个误区是认为 Diversity 等同于微前端框架。实际上 Webpack 5 只解决构建与模块加载，路由、沙箱、样式隔离仍需借助 iframe 或 Shadow DOM 等手段。理清这一边界，才能在旧有项目中以渐进方式引入远程容器，而不必一次性重构整体架构。通过合理划分exposes边界与共享范围，多元特性就能在保障稳定性的同时，释放团队独立交付的能力。
Webpack_5Diversitymodule_federation修改时间：2026-08-17 21:58:33