

聊聊模块联邦 2.0 的蜕变：从架构升级到跨端探索

ByteDance Web Infra

2025-07-31

导读：原播客来自于👉 Web Worker ——听 Heal 聊前端模块联邦从 1.0 到 2.0 的蜕变在前端项

原播客来自于👉 Web Worker ——听 Heal 聊前端模块联邦从 1.0 到 2.0 的蜕变

在前端项目日益庞大的趋势下，模块化和低耦合已经成为主旋律。模块联邦（Module Federation）作为 Webpack 5 引入的重要功能，正在不断演化，朝着更加通用和灵活的方向发展。随着社区需求的增加和使用场景的扩展，模块联邦迎来了 2.0 版本的革新。

本文整理自字节跳动 Web Infra 团队的 Heal 同学对于模块联邦 2.0 的播客内容分享，Heal 同学作为这项技术的核心开发者，从技术背景到功能升级，再到实际应用和未来规划，用通俗易懂的方式为用户呈现了模块联邦 1.0 到 2.0 蜕变历程和技术更新的最新进展。

无论你是刚接触微前端的新人，还是希望深入了解模块联邦实际应用的开发者，都能在这里找到实用信息和启发。

模块联邦 2.0 是什么？

模块联邦最初诞生于 Webpack 5，用于实现不同应用之间的模块共享和解耦部署。它是微前端发展过程中诞生的一种核心机制，但也因过于依赖 Webpack、缺乏统一实践，在实际应用中暴露出种种限制。

模块联邦 2.0 是原作者 Zack Jackson (Twitter @ScriptedAlchemy) 与字节跳动 Web Infra 团队合作推进的重构版本，脱离了对 Webpack 的依赖，支持多构建工具接入（如 Rspack、Vite、Metro），并针对组件共享、模块动态加载等场景进行了大量功能强化。

它不仅是一次技术升级，更是一次架构范式上的进化。

模块联邦适合解决哪些问题？

模块联邦适用于多团队协作、模块解耦、按需加载等复杂业务场景，常见于：

中后台平台与多业务模块共享：不同业务团队需在同一个平台下共享 UI 组件或核心能力。
插件化架构：如门户首页、可视化看板，支持将模块以“插件”形式动态注入和渲染。
远程组件加载与独立部署：前端模块不打包到主项目中，而是按需加载远程资源，提升开发与部署效率。

在传统方案中（如 Monorepo），这些需求往往要靠复杂的脚本或平台层打通。而模块联邦则以一种更“底层、通用”的协议形式完成模块通信与共享，是构建大型系统架构的关键基建能力。

1.0 的痛点，2.0 怎么解决？

模块联邦 1.0 最大的限制在于：

深度依赖 Webpack，其他构建工具难以复用
缺少调试能力，远程模块开发体验不佳
没有统一的类型系统和版本控制
文档薄弱，上手门槛高

而 2.0 在架构和开发体验上都做了重构：

✅ 支持构建工具无关的 runtime 接入

✅ 增加 Hook 机制，方便扩展模块加载逻辑

✅ 提供 CLI、插件工具，快速上手并支持类型自动生成

✅ 文档体系更完善，开箱即用

更重要的是，2.0 引入了“协议规范”机制，让跨团队协作、版本回退、线上联调等高级需求成为可能。

协议规范：模块联邦的“通用语言”

在 2.0 中，模块联邦的运行时与构建工具解耦，通过一套独立协议记录模块元信息。这些元信息包括：

模块导出内容
类型定义文件地址
JS/CSS 资源地址
公共路径（publicPath）

这意味着开发者不再被构建工具框架束缚，而是通过统一的协议与 runtime 实现解耦发布、动态加载、类型协作等能力。

这也是团队后续计划将模块联邦拓展至服务端、AI 生成场景、多端（如 App）协作的技术基础。

支持哪些构建工具？

目前官方支持：

✅ Webpack
✅ Rspack

社区已有初步探索：

⚙️ Vite（通过插件接入）
⚙️ Metro（React Native 构建工具）
⚙️ Rollup 等 bundler

无论是使用 Webpack、Vite，还是跨端构建工具，只要产物符合模块联邦协议，都可以被统一消费。

发展历程与社区现状

模块联邦 2.0 的诞生源于真实的工程痛点。团队在已有 Garfish（微前端沙箱框架）的基础上，希望实现更细粒度、更灵活的模块共享，于是逐步在内部打磨出 2.0 雏形。

早期团队曾尝试将模块联邦作为 “loader” 使用，但运行时能力受限，最终通过引入 Hook 机制解决了这一问题。随后结合 Rspack 的性能优势，团队决定将通用能力开源，并由作者 Zack Jackson 与字节团队一同推动。

目前，模块联邦 2.0 已开源，GitHub star 超过 2000，社区保持活跃，用户每周下载量超过 370 万次。

如何参与或使用模块联邦？

想快速上手模块联邦项目？你可以：

查看模块联邦 GitHub 项目与 roadmap
关注文档教程，使用 CLI 快速创建可运行项目
加入社区交流群（飞书群/discord），与开发者一起讨论
使用 DeepWiki 工具辅助理解源码与架构

💡 注：DeepWiki 是一款辅助开源项目理解的工具，可生成架构图并支持源码问答，曾被 Volar 作者推荐。

模块联邦 vs 微前端

模块联邦和微前端在很多项目中是互补关系：

场景	更适合使用
组件共享、依赖管理	模块联邦
应用隔离、安全沙箱	微前端框架（如 Garfish）
SSR 场景、性能敏感	模块联邦
子应用独立运行	微前端

模块联邦也支持导出应用级模块，但需注意跨框架集成与依赖共享的配置。

探索中的方向：性能突破与跨端拓展

除了帮助跨团队协同开发，提高迭代效率之外，性能是模块联邦核心价值主张之一，但同时也是一个不断需要优化的领域。

已解决的性能问题： MF 通过共享依赖、按需加载远程模块，显著减少了应用的初始加载体积和重复打包，这本身就是巨大的性能提升。
探索中的性能方向： 性能优化是永无止境的。MF 的未来探索包括：

更智能的预加载/预获取: 在用户无感知的情况下，更精准地预加载需要的远程模块
运行时开销优化: MF 的运行时协调逻辑本身有微小的性能开销，将其降到极致
RSC: 配合 React 19 核心功能，进一步提升构建和运行时的性能
全面锈化: 充分利用 Rust 高性能特性，将当前 Manifest 等功能 Rust 化，进一步提升 MF 的编译性能。

同时模块联邦会持续拓展生态，支持更多的平台，以达到真正的“模块联邦”。接下来我们会探索支持下列平台：

Node.js 端 (服务端/SSR，正在普及): 通过 @module-federation/node 等方案，MF 已经可以运行在 Node.js 环境中，实现了前后端模块的复用和同构渲染。这虽然已有方案，但简化使用、提升性能仍在探索中。
移动原生端 (Lynx/React Native 等，前沿探索): 结合跨端方案 Lynx，将模块联邦用于 App 场景，实现 Web 与端侧模块的灵活拼接