Module Federation是Webpack 5引入的官方模块共享方案，它允许不同构建产物在运行时互相消费对方导出的代码，而不必在编译期把依赖打在一起。这种能力让多个独立团队维护的前端应用可以像使用npm包一样使用彼此的功能，却无需重新打包发布。
基础示例：暴露与消费
在官方examples中，最基础的结构包含一个remote应用和一个host应用。remote通过webpack.config中的ModuleFederationPlugin把某些文件标记为对外暴露的模块，host则声明要从哪个地址加载这些模块。两者各自拥有独立的入口和构建输出，但在浏览器里host能直接import remote导出的组件。
remote端的配置通常这样写：在plugins里加入new ModuleFederationPlugin，设置name为app1，filename为remoteEntry.js，exposes里把./Button映射到本地src/Button.js。host端则在remotes里写app1: 'app1@http://localhost:3001/remoteEntry.js'。这样host代码里就能写import('app1/Button')来使用远端按钮。这种写法把部署地址和模块名解耦，方便后续切换环境。
为什么需要独立的remoteEntry
remoteEntry.js是一个很小的清单文件，它不包含业务代码，只描述远端提供了哪些模块以及去哪里加载它们。浏览器先拉取这个清单，再按需请求真正的chunk。这样的设计让host不必在构建时知道remote的具体实现，只依赖约定好的模块名。
如果remote更新了Button的内部逻辑但导出接口没变，host无需重新构建，刷新页面即可拿到新代码。这对需要独立发布节奏的团队非常关键，也是传统npm依赖做不到的地方。
shared依赖的处理
当host和remote都用了React或Vue等库，直接各自打包会导致页面加载多份重复框架代码。examples里用shared字段来解决这个问题。在两端配置中都声明shared: { react: { singleton: true }, 'react-dom': { singleton: true } }，Webpack会保证运行时只加载一份符合条件的React实例。
singleton设为true表示全局只允许一个该模块实例，避免hooks报错。还可以加requiredVersion来约束最低版本，若两端版本不兼容，Webpack会在控制台给出警告。实际项目中建议把高频且体积大的库都放进shared，而业务组件走exposes即可。
共享配置的注意事项
shared并不是万能的，若remote使用的React特性依赖了某个host没装的高版本，运行时仍可能异常。因此团队间需要约定基础依赖的版本基线，并在CI里做兼容性检查。examples中的advanced模式就演示了如何通过shared的version和strictShareMismatch来控制容错行为。
另外，shared的加载策略分为eager和懒加载，默认是懒加载以减小首屏体积。若某些库必须在首屏前就绪，可标记eager: true，但会增加初始bundle大小，需要权衡。
常见示例模式对比
官方仓库提供了多种组合方式，下面用表格列出三种典型示例的核心差异，方便按场景选用。
| 示例名称 | 主要特点 | 适用场景 |
|---|---|---|
| basic | 单向remote暴露，host静态引用 | 主站嵌入子团队组件 |
| dynamic-remote | host运行时决定加载哪个remote | 多租户或插件化架构 |
| bidirectional | 两端互相暴露并消费 | 平等协作的微前端群 |
dynamic-remote示例里，host通过动态拼接remote地址实现按需加载不同实现，比如根据路由切换不同的报表模块。bidirectional则展示两个应用互相引用，常用于旧系统拆分时暂时保留双向依赖。
这些模式并不互斥，真实项目往往组合使用。比如主壳用dynamic-remote加载多个子站，子站之间用bidirectional共享通用头尾。理解examples的目录结构，比直接抄配置更重要。
落地时的实践经验
从examples迁移到生产，第一步是把localhost地址换成带环境变量的远程域名，并给remoteEntry加长缓存头。第二步是在host的错误处理里捕获加载远程模块失败的情况，避免单点故障拖垮整个页面。第三步是建立模块契约测试，保证remote改了导出不会悄悄破坏host。
很多团队一开始把太多东西塞进shared，结果构建变慢且版本冲突变多。更稳妥的做法是先只共享框架级依赖，业务模块走exposes，等边界稳定后再逐步扩大共享范围。examples里的todo-app和dashboard都是不错的参照模板。
Module Federation不是微前端的最终形态，但它用极低的接入成本解决了最痛的代码级复用问题。
当你能把一个巨石应用拆成数个独立仓库、各自部署却共享界面与状态，研发效率的提升会非常明显。建议从examples的basic跑通开始，再逐步尝试动态与双向模式。
Module_FederationWebpack5微前端修改时间：2026-08-11 07:27:26