随着企业级 Web 应用的体量日益膨胀,传统的单体前端(Monolithic Frontend)架构在开发效率、团队协作和部署灵活性上正面临着巨大挑战。

**微前端(Micro-frontends)**作为后端微服务概念在前端的延伸,提倡将庞大的单体应用拆分为若干个独立开发、独立测试、独立部署的子应用。而 Webpack 5 引入并在 2025 年得到广泛普及的 Module Federation(模块联邦),已然成为微前端落地的最佳技术方案之一。

为什么选择 Module Federation?

在传统的微前端方案中(如 iframe 隔离、qiankun 路由劫持),子应用之间的资源共享和通信往往存在较大的性能开销。

Module Federation 允许一个 JavaScript 应用在运行时动态加载并直接运行另一个应用的渲染组件和代码块,而无需在构建时进行物理打包。

1
2
3
4
5
6
┌──────────────────────────────────────────────┐
│ Host Application (容器) │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Nav App (Remote)│ │ Auth App(Remote)│ │
│ └──────────────────┘ └──────────────────┘ │
└──────────────────────────────────────────────┘
  1. 去中心化:每个应用都可以既是宿主(Host)接收其他组件,也可以是远程(Remote)暴露组件。
  2. 极速共享:在运行时以原生速度加载,且支持依赖共享(如 React/Vue 本身不会被重复下载)。
  3. 独立部署:Remote 应用升级部署后,Host 容器应用无需重新打包,刷新浏览器即可渲染最新功能。

代码实战:配置 Module Federation

以基于 Webpack 的子应用配置为例,将头部导航组件 Header 暴露给主应用。

1. 远程子应用配置 (Remote)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// remote/webpack.config.js
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'remoteApp',
filename: 'remoteEntry.js',
exposes: {
'./Header': './src/components/Header', // 暴露头部组件
},
shared: {
react: { singleton: true, requiredVersion: '^18.2.0' },
'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
},
}),
],
};

2. 主应用配置 (Host)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// host/webpack.config.js
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin');

module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'hostApp',
remotes: {
remoteApp: 'remoteApp@http://localhost:3001/remoteEntry.js', // 注入子应用地址
},
shared: {
react: { singleton: true, requiredVersion: '^18.2.0' },
'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
},
}),
],
};

总结

Module Federation 极大降低了微前端架构的上手门槛与运行时损耗。在 2025 年,随着大前端工程化体系日趋成熟,微前端与模块联邦已经不仅仅是中大型团队的“玩具”,而是构建高可用、跨团队、敏捷部署的现代化企业级 Web 应用的坚实基石。