Module Federation 都 2026 了还只会基础配置？这 5 个高级模式让你的微前端再上一个台阶

阿柯·前端架构内容创作者 2026-07-13 0 阅读

Module Federation 都 2026 了还只会基础配置？这 5 个高级模式让你的微前端再上一个台阶

导语

很多团队用 Module Federation 做微前端，搞了几个月还是老一套：一个 host 配几个 remote，暴露几个组件，完事。但当你遇到共享依赖版本冲突、多级嵌套联邦、动态加载远程容器、异构构建工具混搭这些真实场景时，基础配置根本不够用。我花了两年时间在三个不同规模的项目里折腾 Module Federation，从 Webpack 5 一路跟到 @module-federation/vite 和 Rspack 生态，踩了无数坑，沉淀了这 5 个值得每个前端架构师掌握的高级模式。

模式一：共享依赖的版本仲裁与安全逃生

这是绝大多数人搞不清的。shared 配置看起来就那几行，但真实项目的依赖冲突能让你查三天。

先看一个常见的错误配置：

// ❌ 问题配置
new ModuleFederationPlugin({
  name: 'host',
  remotes: { app1: 'app1@http://localhost:3001/remoteEntry.js' },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
    antd: { singleton: true }
  }
})

singleton: true 只告诉 Webpack “全局只加载一份”，但如果没有 requiredVersion，当 host 用 antd 5.12、remote 用 antd 5.8 时，Webpack 会用先加载的那个版本。如果两个版本之间有 breaking change，你的页面可能直接白屏。

正确的做法是显式声明版本范围并启动版本校验：

// ✅ 生产级配置
new ModuleFederationPlugin({
  name: 'host',
  remotes: { app1: 'app1@http://localhost:3001/remoteEntry.js' },
  shared: {
    react: {
      singleton: true,
      requiredVersion: '^18.2.0',
      strictVersion: true,    // 版本不匹配直接报错，比白屏好查
      version: '18.2.0'
    },
    'react-dom': {
      singleton: true,
      requiredVersion: '^18.2.0',
      strictVersion: true,
      version: '18.2.0'
    },
    antd: {
      singleton: true,
      requiredVersion: '^5.0.0',
      version: '5.12.0',
      shareKey: 'antd',       // 自定义共享 key，用于跨应用匹配
      shareScope: 'default'
    }
  }
})

关键参数含义：

singleton：全局只加载一个实例（React 这类库必须开）
requiredVersion：声明你期望的版本范围
strictVersion：版本不匹配直接抛错
shareKey：多个包有相同 identity 时用来合并
version：显式告诉 federation 你的版本号

遇到版本冲突时的安全逃生： 在前面的 strictVersion 模式下，如果 remote 依赖的版本与 host 不一致会抛错。你可以用 eager: false + 异步加载策略来兜底：

shared: {
  antd: {
    singleton: true,
    requiredVersion: '^5.0.0',
    eager: false,  // 不在入口处加载，让 Module Federation 按需协商
    import: false  // 不自动注入 fallback
  }
}

模式二：动态远程容器——运行时决定加载谁

基础模式里，remotes 是写死在 Webpack 配置里的。这意味着每次新增一个微应用，你都得改配置重新构建。这在多团队场景下根本行不通——你不能因为 B 团队上线了新应用，就让 A 团队重新部署。

动态 remote 的解法：

// webpack.config.js - host 配置
new ModuleFederationPlugin({
  name: 'host',
  // 不在这里写死 remotes！
  shared: { react: { singleton: true, requiredVersion: '^18.2.0' } }
})

然后在运行时动态加载：

// runtime 动态加载 remote
async function loadRemoteApp(name, url) {
  // 通过 __webpack_init_sharing__ 初始化共享作用域
  await __webpack_init_sharing__('default');

  // 动态创建 script 标签加载 remoteEntry
  const script = document.createElement('script');
  script.src = url;
  script.onload = async () => {
    // 此时 container 已经注册到全局
    const container = window[name];

    // 初始化容器，传入共享作用域
    await container.init(__webpack_share_scopes__.default);

    // 动态加载远程模块
    const factory = await container.get('./App');
    const App = factory();
    // 渲染到页面
    renderApp(App);
  };
  document.head.appendChild(script);
}

// 从配置中心动态获取微应用列表
const apps = await fetch('/api/micro-apps').then(r => r.json());
apps.forEach(app => loadRemoteApp(app.name, app.remoteEntry));

这个模式的核心价值：你只需要一个中心化的注册表（可以是一个 JSON 配置、一个 API 接口或者 Nacos 配置中心），所有微应用的加载策略都在运行时决定。新应用上线只需要在注册表里加一条记录，host 零改动。

在这个基础上，还可以做更高级的灰度发布：

async function getRemoteEntry(appName) {
  const config = await fetchConfig();
  const userGroup = getUserGroup(); // 从 cookie/SSO 获取用户分组

  // 不同用户组加载不同的 remoteEntry
  if (userGroup === 'canary') {
    return config.apps[appName].canaryEntry;
  }
  return config.apps[appName].stableEntry;
}

模式三：多级联邦——App 嵌套 remote 再 remote

真实微前端架构很少只有两层（host → remote）。更常见的是：门户应用 A → 业务应用 B → 基础组件库 C。这种三层甚至四层嵌套，基础配置会直接崩溃。

核心问题在于：C 暴露的模块要通过 B 透传给 A，而 A 和 B 都需要共享依赖。

// C - 基础组件库
new ModuleFederationPlugin({
  name: 'lib_c',
  filename: 'remoteEntry.js',
  exposes: {
    './Button': './src/components/Button',
    './Table': './src/components/Table',
    './hooks': './src/hooks/useAuth'
  },
  shared: { react: { singleton: true, requiredVersion: '^18.2.0' } }
})

// B - 业务应用（既是 host 又是 remote）
new ModuleFederationPlugin({
  name: 'app_b',
  filename: 'remoteEntry.js',
  remotes: {
    lib_c: 'lib_c@http://cdn.example.com/lib_c/remoteEntry.js'
  },
  exposes: {
    './OrderPage': './src/pages/Order',
    './UserProfile': './src/pages/Profile'
  },
  shared: { react: { singleton: true, requiredVersion: '^18.2.0' } }
})

// A - 门户（host）
new ModuleFederationPlugin({
  name: 'app_a',
  remotes: {
    app_b: 'app_b@http://cdn.example.com/app_b/remoteEntry.js',
    lib_c: 'lib_c@http://cdn.example.com/lib_c/remoteEntry.js' // 也可以直接引用 C！
  },
  shared: { react: { singleton: true, requiredVersion: '^18.2.0' } }
})

多级联邦的几个关键原则：

1. 依赖版本必须全局一致：React、Vue 这类框架库在整条链路上必须用同一版本。不一致的话，B 中的 Button 拿的是 C 的 React 实例，A 中的其他组件拿的是 A 的 React 实例，useContext 直接炸裂。

2. 共享作用域可以隔离：如果部分 remote 必须用不同版本的依赖，可以用 shareScope 隔离：

// 在主共享作用域之外创建一个隔离作用域
shared: {
  'antd': {
    singleton: true,
    shareScope: 'v4-scope',  // 隔离到独立作用域
    requiredVersion: '^4.0.0'
  }
}

3. 不要试图把所有东西都共享：只共享运行时代理（React、Vue、Router），工具库（lodash、dayjs）各带各的反而更稳。

模式四：异构构建工具混搭——Webpack + Vite + Rspack 共存

2026 年的前端生态已经不是 Webpack 一家独大的局面了。你的团队可能有的用 Vite，有的切了 Rspack，还有历史项目在 Webpack 上。Module Federation 能跨构建工具工作吗？答案是可以，但需要适配层。

场景：Webpack host 加载 Vite remote

Vite 本身不支持 Module Federation，你需要用社区插件：

// Vite remote 侧 — vite.config.js
import federation from '@module-federation/vite';

export default defineConfig({
  plugins: [
    react(),
    federation({
      name: 'vite_remote',
      filename: 'remoteEntry.js',
      exposes: {
        './UserCard': './src/components/UserCard'
      },
      shared: ['react', 'react-dom']
    })
  ],
  build: {
    target: 'esnext',
    cssCodeSplit: false
  }
})

Webpack host 侧完全不用改，直接用 remotes: { vite_remote: 'vite_remote@...' } 引用。

场景：Rspack + Module Federation

Rspack 的 Module Federation 支持已经相当成熟，连 Nx 官方都在推。用法和 Webpack 几乎一致：

// Rspack 配置
const rspack = require('@rspack/core');

module.exports = {
  plugins: [
    new rspack.container.ModuleFederationPlugin({
      name: 'rspack_remote',
      filename: 'remoteEntry.js',
      exposes: {
        './SearchWidget': './src/components/SearchWidget'
      },
      shared: ['react', 'react-dom']
    })
  ]
};

经验总结：

组合	可行性	注意事项
Webpack host → Webpack remote	✅ 原生支持	最稳，推荐生产使用
Webpack host → Vite remote	✅ 可行	用 @module-federation/vite，注意 ESM 兼容
Vite host → Webpack remote	✅ 可行	同上插件，需配置 library.type
Rspack host → Webpack remote	✅ 可行	配置基本一致，构建速度快 10x
Vite host → Vite remote	✅ 可行	注意版本号匹配

模式五：联邦模块的缓存与预加载策略

MF 的一大槽点是：remoteEntry.js 的加载延迟会影响首屏。每一个 remote 应用都需要先拉取 remoteEntry，再请求对应的 chunk，多了一层网络开销。

解决方案 1：预加载关键 remote

// Webpack 5 原生支持 preload
new ModuleFederationPlugin({
  name: 'host',
  remotes: {
    critical_app: 'critical_app@http://...'
  },
  shared: ['react', 'react-dom']
})

在入口处提前加载：

// 在应用初始化阶段就开始加载
const preloadRemote = async (name, url) => {
  const link = document.createElement('link');
  link.rel = 'preload';
  link.as = 'script';
  link.href = url;
  document.head.appendChild(link);
};

// 关键应用立即预加载
preloadRemote('critical_app', 'http://cdn.example.com/critical_app/remoteEntry.js');

// 非关键应用可以延迟到空闲时加载
requestIdleCallback(() => {
  preloadRemote('analytics_app', 'http://cdn.example.com/analytics_app/remoteEntry.js');
});

解决方案 2：CDN 缓存策略

remoteEntry.js 默认是不带 hash 的，需要手动配置：

// Webpack
output: {
  filename: '[name].[contenthash:8].js',
  chunkFilename: '[name].[contenthash:8].chunk.js'
}

// Module Federation 插件中
new ModuleFederationPlugin({
  name: 'app',
  filename: 'remoteEntry.[contenthash:8].js',  // 给 remoteEntry 也加 hash！
})

然后在注册表里维护最新的 remoteEntry 地址，让 host 始终加载最新的版本。同时 CDN 上配置 Cache-Control: public, max-age=31536000, immutable——文件名带 hash 的内容永远缓存，不回源验证。

解决方案 3：Service Worker 缓存联邦模块

对于 offline-first 场景，可以用 Service Worker 提前缓存 remoteEntry 和关键 chunk：

// service-worker.js
const REMOTE_ENTRIES = [
  'https://cdn.example.com/app_a/remoteEntry.abc123.js',
  'https://cdn.example.com/app_b/remoteEntry.def456.js'
];

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('mf-remotes-v1').then(cache => {
      return cache.addAll(REMOTE_ENTRIES);
    })
  );
});

self.addEventListener('fetch', event => {
  if (event.request.url.includes('remoteEntry')) {
    event.respondWith(
      caches.match(event.request).then(cached => {
        // 缓存优先，后台更新
        return cached || fetch(event.request);
      })
    );
  }
});

总结：什么时候该上高级模式？

分享一个判断标准：如果你们的项目满足以下任意 3 条，就是时候用这些高级模式了：

微应用数量超过 5 个
多团队并行开发，发版节奏不同
需要灰度发布 / A/B 测试微应用
有历史遗留的 Webpack 项目和新 Vite 项目共存
首屏加载时间要求 2 秒以内
需要多级嵌套引用（应用引组件库）

第一步可以做什么？ 从模式二开始——先搭一个动态 remote 的注册表。它成本最低、收益最大，而且为后续所有高级模式铺平了道路。等你把动态加载跑通了，再逐步引入版本仲裁、预加载策略，你的微前端架构才能真正撑到生产环境不翻车。

评论区

0 条评论

登录后可评论。

Module Federation 都 2026 了还只会基础配置？这 5 个高级模式让你的微前端再上一个台阶