Module Federation 是 Webpack 5 提供的一种模块共享机制，特别适合微前端架构中多个独立应用之间的代码复用和运行时集成。如果你正在维护两个以上的前端应用，且它们由不同团队开发、独立部署，但需要在某个主页面中组合使用，那么 Module Federation 可以帮你避免重复打包公共库，并实现按需加载远程组件。

适用场景与基础配置

在使用 Module Federation 前，确保主应用与子应用均基于 Webpack 5。主应用通过 exposes 暴露组件，子应用通过 remotes 引用。例如，主应用配置 exposes: {'./Button':'./src/Button'}，子应用配置 remotes: {app1:'app1@http://localhost:3001/remoteEntry.js'}。注意每个应用需单独打包，且 remoteEntry.js 不能合并到其他 chunk 中，否则会导致加载失败。这段配置明确了两个角色的分工：主应用决定暴露哪些模块，子应用声明要消费哪些远程模块。这里的远程入口 remoteEntry.js 是模块联邦的契约文件，运行时主应用通过它获取子应用的暴露列表。

常见陷阱是忘记在子应用的 Webpack 配置中设置 publicPath。如果你的子应用部署在 CDN 或非根路径下，需要显式指定 publicPath，否则加载子应用 chunk 时会请求错误路径。检查方法：在浏览器开发者工具网络面板过滤 remoteEntry.js，确认加载成功并查看响应内容中 exposes 对象的键名是否与主应用引用名称一致。

共享依赖的版本管理

通过 shared 配置共享公共库，避免重复加载。例如 shared: {react:{singleton:true,requiredVersion:'^17.0.0'},'react-dom':{singleton:true}}。当子应用的主版本与主应用不一致时，设置 eager:true 可同步加载，但会增加初始包体积。若版本不兼容，建议使用 fallback 配置降级版本，并设置 strictVersion:false 允许小版本差异。这个配置项直接影响到运行时是否加载重复的 React 实例。singleton: true 是关键：它保证整个页面只有一个 React 实例，避免因多实例导致的 context 丢失问题。但如果主应用用 React 17 而子应用用 React 18，singleton 会强制使用主应用的 17，可能引发子应用内部 API 不兼容。此时可以先检查子应用是否真的依赖 18 的新特性，如果不是，让子应用降级到 17 或使用 fallback 加载 18 版本并接受多实例风险。

另外，shared 配置中的 eager 属性要谨慎使用。eager: true 会让该依赖直接打包进主 chunk，而不是异步加载。如果你在主应用入口就需要使用共享库，可以考虑 eager，否则建议默认 false，让依赖只在首次消费时加载。验证方法：构建后查看 output 文件，如果 shared 库出现在主入口 chunk 中，说明 eager 生效。

动态加载与隔离措施

微前端场景下，建议动态加载远程组件而非静态导入。使用 React.lazy(() => import('app1/Button')) 配合 Suspense 实现按需加载。注意远程应用的入口文件需支持跨域，需在开发环境配置 Access-Control-Allow-Origin。若生产环境使用同一域名，可省略跨域配置，否则需在 Nginx 添加头信息。动态加载的好处是子应用代码只在需要时下载，减小首屏体积。但注意 Suspense 的 fallback 不能太简单，建议使用骨架屏或 loading 动画，否则用户会感知到明显的白屏。

Module Federation 默认不隔离样式和全局变量。可通过 CSS Modules 或 CSS-in-JS 避免样式冲突。对于全局变量，建议使用 Webpack 的 output.library 配置，如 output: {library:{type:'module'}}。若子应用间存在命名冲突，可在加载时使用沙箱，如 iframe 或 Shadow DOM，但会增加性能开销。仅在必要场景使用。通常先尝试 CSS Modules，因为成本最低，只需要在 Webpack 配置中添加 css-loader 的 modules 选项。如果全局变量冲突（比如两个应用都向 window 挂载了同名对象），可以通过 Webpack 的 externals 或 output.library 将子应用打包成 ESM 模块，避免污染全局。

部署要点与缓存策略

部署时需确保 remoteEntry.js 及其引用的 chunk 文件可通过绝对路径访问。建议将每个微应用独立部署到不同子域名或路径下，并在主应用配置中统一维护远程入口 URL。若使用 CDN，注意配置正确的跨域头。更新子应用后，主应用无需重新部署，但需保证缓存策略合理，避免旧版本 remoteEntry 被缓存。这里的关键是 remoteEntry.js 的缓存有效期要短，比如设置 max-age=0 或使用版本哈希文件名。如果 CDN 强缓存了旧版 remoteEntry.js，子应用更新后主应用仍然加载旧版本，导致模块加载失败。建议在子应用构建时给 remoteEntry.js 加上内容哈希（Webpack 默认支持），这样文件名会随内容变化，CDN 也能自然失效。

另一个容易忽略的点是跨域。如果子应用部署在另一个域名下，必须确保服务端返回 Access-Control-Allow-Origin: * 或具体允许的主域名。开发环境可以通过 Webpack Dev Server 的 headers 配置添加。生产环境检查方法：打开浏览器控制台，观察 network 请求中的响应头是否包含跨域头。

调试与常见坑

启用 Webpack 的 devtool: 'source-map' 便于调试。在浏览器控制台可通过 window.__webpack_require__ 检查已加载模块。若遇到远程模块未加载，检查网络请求是否 404，并确认 remoteEntry.js 中 exposes 的对象名与实际引用一致。常见坑：忘记在子应用 webpack 配置中设置 publicPath 为 CDN 地址，导致资源路径错误。调试时先确认远端入口文件能否直接访问，然后在主应用控制台执行 __webpack_require__('your_remote_scope') 查看容器对象。如果获取不到，说明 remoteEntry.js 加载失败或容器注册冲突。另外，注意浏览器缓存：如果修改了 remoteEntry.js 但浏览器加载旧版本，可以手动清除缓存或使用版本哈希文件名规避。