目录 (Outline)
- 一、 架构演进：从静态编译到运行时分发
- 二、 核心原理：Module Federation 的远程加载机制
- 三、 实战 1：配置支持动态注入的宿主应用 (Host)
- 四、 实战 2：开发并发布一个远程插件组件 (Remote)
- 五、 进阶：插件的版本管理与依赖共享策略
- 六、 总结与最佳实践
一、 架构演进：从静态编译到运行时分发
1. 历史背景
早期的插件系统通常依赖于 npm install。这意味着每次插件更新，主应用都必须重新构建、部署。
- 痛点：发布周期长，无法实现「即插即用」。
2. 标志性事件
- 2020 年：Webpack 5 发布，正式引入 Module Federation。
- 2022 年：社区涌现出基于模块联邦的插件框架（如 Medusa）。
二、 核心原理：Module Federation 的远程加载机制
模块联邦允许一个应用在运行时，从另一个服务器上直接「拉取」编译好的代码块，并像使用本地模块一样引用它。
- 优势：宿主应用不需要在编译时知道插件的存在，只需要知道插件的 URL 即可。
三、 实战 1：配置支持动态注入的宿主应用 (Host)
宿主应用需要能够根据数据库或配置文件中的 URL，动态加载远程容器。
代码示例：动态加载工具函数
// utils/loadModule.js
export async function loadRemoteComponent(url, scope, module) {
// 1. 动态插入远程入口脚本
await __webpack_init_sharing__("default");
const container = window[scope]; // 获取全局容器
await container.init(__webpack_share_scopes__.default);
// 2. 获取并返回模块
const factory = await container.get(module);
return factory();
}
四、 实战 2：开发并发布一个远程插件组件 (Remote)
插件开发者只需导出特定的组件即可。
插件配置 (webpack.config.js)
new ModuleFederationPlugin({
name: "plugin_marketing",
filename: "remoteEntry.js",
exposes: {
"./Banner": "./src/components/Banner.jsx",
},
shared: ["react", "react-dom"],
});
五、 进阶：插件的版本管理与依赖共享策略
1. 依赖冲突处理
如果插件需要 React 18 而宿主是 React 17 怎么办？
- Singleton 模式：通过
shared配置强制使用单例，Webpack 会根据 SemVer 规则自动选择最合适的版本。
2. 灰度分发
由于插件是通过 URL 加载的，你可以非常容易地实现灰度发布：
- 不同用户返回不同的
remoteEntry.js地址即可。
六、 总结与最佳实践
- 隔离性：建议配合 CSS Modules 或 Shadow DOM，防止插件样式污染宿主。
- 安全性：务必对远程脚本进行签名验证或设置严格的 CSP 策略。
- 建议：对于中后台系统，模块联邦是实现「模块化定制」的最优解。
通过 Module Federation，我们真正实现了「应用即服务（Apps as Services）」，让前端架构拥有了无限的扩展可能。
