一个核心结论是：在 Webpack Module Federation 微前端架构中实现可靠的模块共享，关键在于精确区分宿主应用（Host）与远程应用（Remote）的 shared 配置策略。两者写法看似接近，但配置逻辑与目标截然不同，理解其中的差异是避免“假共享”和运行时错误的前提。

实际开发中，团队常遇到的 React 实例冲突、样式混乱或模块加载失败等问题，根源往往不在于 Federation 方案本身，而是 shared 依赖配置不当。一个典型的误区是仅简单列出依赖名称，这几乎无法实现有效的运行时共享，最终导致应用打包体积膨胀、状态管理异常。

宿主应用（Host）的共享依赖配置

宿主应用作为微前端架构的基石，其 shared 配置至关重要。在主应用的 webpack.config.js 中，定位到 ModuleFederationPlugin 插件的 shared 字段，这里需要采用对象形式进行精细化声明。

必须避免直接使用数组简写形式，例如 shared: ["react", "react-dom"]，这会导致 singleton（单例模式）、requiredVersion（版本约束）等重要配置项失效，使得共享机制形同虚设。

正确的配置方式是为每个需要共享的库定义配置对象，至少明确以下关键属性：

shared: { react: { singleton: true, requiredVersion: "^18.2.0" }, "react-dom": { singleton: true, requiredVersion: "^18.2.0" }, lodash: { singleton: false, eager: true } }

其中，requiredVersion 属性是一条必须严格遵守的版本兼容规则。它必须与宿主应用 node_modules 中实际安装的依赖版本范围相匹配。例如，若宿主安装的是 react@18.3.1，但配置中写为 requiredVersion: "^17.0.0"，Webpack 在运行时将判定版本不兼容，进而为远程应用加载一个独立的 React 副本。这会导致 React 单例被破坏，可能引发组件上下文丢失、Hooks 执行错乱等难以追踪的运行时缺陷。

远程应用（Remote）复用宿主共享依赖

远程应用的目标是尽可能复用宿主已提供的共享依赖，避免重复打包。因此，其 shared 配置应被视为与宿主对齐的“声明式契约”。

配置的关键在于与宿主方保持绝对一致：依赖的名称拼写（包括大小写与连接符）、配置的对象结构以及 requiredVersion 的版本字符串都必须严格匹配。例如，宿主配置为 "react-dom"，远程方绝不能简写为 reactdom。Webpack 内部采用字符串精确匹配逻辑，任何细微差异都会导致依赖被视为独立模块，从而引发重复打包与共享失效。

需注意的是，配置不一致在构建阶段通常不会直接报错，仅在浏览器控制台输出警告信息（如 “Multiple instances of React found”）。等问题在用户侧运行时暴露，再追溯版本与配置差异，排查成本将显著增加。

动态共享团队内部工具模块

除了 React、Lodash 等第三方库，团队内部的工具函数、业务组件或工具模块也可纳入共享体系，提升整体复用性与一致性。主流实现方式有两种。

方法一：通过 exposes + shared 注册为“准公共依赖”
此方法将内部模块模拟为公共库进行注册。首先，在远程应用配置中通过 exposes 暴露模块路径，如 exposes: { "./utils": "./src/utils/index.ts" }。随后，在同一配置的 shared 字段中，添加同名条目并配置 shareKey、shareScope 等属性，将其标记为可共享模块。这样，宿主及其他远程应用即可像引用标准库一样，稳定、类型安全地调用该工具集。

方法二：使用动态导入（import()）按需加载
若工具模块仅在特定场景下偶尔使用，可跳过复杂的 shared 配置，直接在宿主代码中使用动态导入语法：const { formatDate } = await import("remote-app/utils");。这种方式灵活性高，不依赖共享契约，适用于快速集成或原型验证。但其代价是无法利用 Tree-Shaking 优化打包体积，且在部分 TypeScript 配置下类型推导可能不够完善。

两种方案各有侧重：前者适合高复用、稳定迭代的公共模块，强调性能与开发体验；后者更适合临时集成或非核心工具，追求配置简单与快速上线。根据实际场景灵活选择，方能充分发挥 Module Federation 的模块共享能力。