Module Federation核心库中的共享模块加载机制解析

Module Federation作为现代前端微前端架构的核心技术，其共享模块机制在实际应用中常会遇到一些意料之外的行为。本文将深入分析共享模块加载过程中的一个典型问题：当宿主应用先注册共享模块后，远程模块加载时为何会覆盖宿主已注册的模块。

问题现象

在Module Federation架构中，当宿主应用初始化时注册了某些共享模块（如React），随后加载的远程模块如果也共享相同模块，会发现宿主注册的模块会被远程模块的版本覆盖。这种现象即使在宿主将模块声明为单例（singleton）的情况下也会发生。

核心问题在于宿主应用没有在远程模块加载前"预加载"这些共享模块。按照预期，宿主先注册并标记为单例的模块应该被后续所有远程模块使用，而实际情况却相反。

技术原理

Module Federation的共享机制是基于对象合并（Object.assign）实现的。当不同来源的共享模块具有相同版本号时，加载顺序不会影响最终结果，后加载的模块会覆盖先前的注册。

这种设计源于Module Federation的核心假设：相同版本的模块应该是完全兼容的。但在实际应用中，开发者往往期望先加载的宿主模块能保持主导地位。

解决方案

使用loaded-first策略

通过运行时插件可以强制指定共享模块使用"loaded-first"策略：

import type { FederationRuntimePlugin } from '@module-federation/enhanced/runtime';

const sharedStrategy = () => ({
  name: 'shared-strategy-plugin',
  beforeInit(args) {
    const { shared } = args.userOptions;
    if (shared) {
      Object.keys(shared).forEach(sharedKey => {
        const configs = Array.isArray(shared[sharedKey]) 
          ? shared[sharedKey] 
          : [shared[sharedKey]];
        configs.forEach(config => {
          config.strategy = 'loaded-first';
        });
      });
    }
    return args;
  },
});

这种方案在使用@module-federation/enhanced/webpack时有效，但对于传统的webpack/lib/container/ModuleFederationPlugin则不起作用，因为它缺乏运行时插件机制。

直接修改共享作用域

对于无法使用运行时插件的情况，可以直接修改__webpack_share_scopes__对象，手动设置模块的loaded参数。不过这种方法依赖于webpack内部实现，不够优雅。

最佳实践

1. 统一使用增强版：尽可能使用@module-federation/enhanced版本，它提供了更灵活的运行时控制能力。

2. 版本管理：确保宿主和远程模块使用完全兼容的共享模块版本，避免版本冲突。

3. 加载顺序控制：对于关键共享模块，考虑在应用初始化时主动加载，确保其优先占用共享作用域。

4. 监控机制：实现共享模块加载的监控，及时发现和解决意外的覆盖行为。

总结

Module Federation的共享模块机制虽然强大，但也需要开发者深入理解其工作原理。通过合理配置策略和加载顺序，可以确保共享模块按预期工作，避免意外的覆盖行为。随着Module Federation核心库的不断演进（如0.4.0版本已修复此问题），这类问题将得到更好的解决，为微前端架构提供更稳定的基础。