先搞清楚：它们解决的不是同一个问题
做微前端选型时，很多团队会在 single-spa 和 Module Federation 之间来回对比。网上对比文章不少，但大多默认它们是同一类框架，于是结论经常变成“二选一”。事实上，这两个东西的维度并不一样：single-spa 解决的是“怎么把多个应用组织在一个页面壳里”，Module Federation 则解决“怎么在构建和运行时共享模块”。维度不同，选择就变成了一道组合题，而不是单选题。
可以这样理解：single-spa 关心应用级生命周期，它定义了一个应用从加载、挂载到卸载的完整流程。Module Federation 关心模块级引用，它允许一个应用在构建时引用另一个应用暴露出来的代码块，并在浏览器里按需获取。一个偏架构，一个偏构建。
所以，当我们讨论 single-spa 与 Module Federation 的选型时，真正要问的不是“哪个更先进”，而是“你的系统目前卡在哪一层”。
选型之前，先回答四个问题
很多团队一上来就对比技术特性，但真正影响选型的往往是技术之外的因素。我建议先回答四个问题。
- 拆分动机是什么？为了解决发布冲突，还是代码库体积？如果每次发布都要多个团队协调，说明需要应用级隔离；如果只是代码太多，可以先考虑组件库或模块化。
- 技术栈是否同构？几个业务线分别用 React、Vue、Angular，模块级共享会非常痛苦；大家都统一在 React 技术栈下，模块共享才值得优先考虑。
- 团队边界是否清晰？微前端本质上是组织结构的投影。团队之间如果无法定义清晰的工程边界，任何技术方案都会被复杂的人为耦合拖垮。
- 对基础设施的容忍度有多高？single-spa 和 Module Federation 都有实现成本，前者要改造入口并处理样式隔离，后者要接受 Webpack 5 的约束和构建链路改造。
这四个问题不需要立刻给出完美答案，但至少要形成大致结论。否则后面选型很容易被某个 Demo 或 GitHub 星星数带偏。
举个例子：一个典型的中后台系统，四个业务线在同一个仓库里开发，每次发版互相等待，样式偶尔互相污染。这时候你需要的是一个清晰的应用边界，而不是一套复杂的模块共享机制。另一个场景则相反：一个平台只有一个核心应用，团队想把下单流程抽出来给新业务复用。这时你需要的是更轻量的模块化机制，而不是一套完整的微前端运行时。
三种路径对比：single-spa、Module Federation 还是组合
在实际项目中，常见的落地路径有三种：以 single-spa 为核心的集线器模式，以 Module Federation 为核心的共享模块模式，以及两者结合的模式。它们适合的团队、技术和业务阶段差异很大。
| 维度 | 以 single-spa 为主 | 以 Module Federation 为主 | 两者结合 |
|---|---|---|---|
| 拆分粒度 | 应用级、页面级 | 模块级、组件级 | 应用级 + 模块级 |
| 核心技术栈 | 任意，由子应用决定 | 通常要求同构或兼容 | 可以异构，但共享部分需统一 |
| 依赖共享 | 需要自行处理外部化 | 原生支持 shared 依赖 | MF 负责共享，single-spa 负责生命周期 |
| 部署方式 | 子应用独立部署，主应用动态挂载 | 消费方通过远程地址拉取模块 | 子应用独立部署，同时消费远程模块 |
| 学习成本 | 理解注册协议和生命周期改造 | 构建配置复杂，生产环境需要处理缓存和版本一致 | 两者成本叠加 |
| 典型场景 | 多业务线、技术栈差异大 | 同栈团队，公共组件复用频繁 | 大型组织，既要拆分又要共享 |
从表格可以看出，两种技术并不是简单的替代关系。选择以谁为主，取决于你希望把精力花在哪里：是管理应用状态，还是管理模块供给。
一张决策树，把选择变成判断
在开发者思维里，一张清晰的决策树可能比大段文字更有用。以下是一个偏保守、适合绝大多数中大型前端团队的决策逻辑，你可以直接当作选型草稿：
if (需要拆分应用，且子应用技术栈差异大) {
优先选择 single-spa 做路由级集成
} else if (需要共享公共模块，且整体技术栈同构) {
优先选择 Module Federation 做模块共享
} else if (需要应用级拆分，也需要模块级共享) {
single-spa 管应用，Module Federation 管共享
} else {
说明当前还没有必要做微前端
先用单仓或组件库控制边界
}这棵树的判断依据并不复杂。第一个分支的关键是「独立部署 + 异构技术栈」，如果核心痛点是两个团队无法独立发版，single-spa 的注册模型可以马上缓解。第二个分支的关键是「同构技术栈 + 高频共享」，此时引入模块联邦，可以让公共模块的更新不必通过 npm 新版本发布等待。第三个分支则对应最复杂的组织：既有多技术栈的团队，又有需要跨团队复用的业务模块。
为了验证这个问题，你可以做一个简单的映射：你的共享诉求是页面还是代码片段？页面级诉求往应用拆分走，片段级诉求往模块共享走。如果你的答案里两种都有，那就不要挣扎了，规划组合方案吧。
三个容易踩的坑
误区一：认为两者只能选一个
这是最常见的误解。比如你的公司有用户中心和订单中心两个团队，一个用 Vue，一个用 React，同时希望两边复用一套权限组件。这时候如果只选 single-spa，权限组件要么抽成 npm 包，要么在运行时引入第三套构建机制；只选 Module Federation，跨技术栈共享又会遇到框架版本冲突。于是实际项目中，常见的做法反而是用 single-spa 组织页面，用 Module Federation 共享那些无框架依赖的纯逻辑模块。
误区二：把 Module Federation 当成微前端本体
Module Federation 只解决模块的暴露和加载，它并没有定义模块边界、生命周期和应用上下文。很多团队引入 MF 后，很快发现所有页面模块互相引用，最终形成一张网状依赖。与其说这是微前端，不如说是一种动态组件库。如果团队在组织上没有独立的业务边界，MF 并不会自动带来自治能力。
误区三：默认 single-spa 自带隔离能力
single-spa 不会沙箱化你的全局变量，也不会处理样式冲突。它只负责在正确的时间调用子应用的生命周期函数。样式污染、全局对象搞乱、路由状态被覆盖，这些都是迁移过程中很常见但很容易被忽略的问题。你需要额外引入 CSS Modules、Shadow DOM 或 iframe 一类的边界方案，这些成本必须在选型评估时一起算进去。
落地建议：从一个有边界的模块开始
如果团队正处于选型阶段，我建议不要直接对照别人的架构做决定，而是先在一个边缘业务上做一条最小链路。这条链路的规模不需要大，但必须能验证几个关键点：应用如何注册、远程模块如何加载、失败时如何降级、部署后如何独立回滚。
- 从最小单元开始：挑一个依赖少、访问量低的业务线，把它拆成独立子应用。不要一上来就接管整个人工作台或主站。
- 只共享真正被高频使用的基础模块：比如登录态、权限判断、监控 SDK、UI 基础组件。业务逻辑模块不建议一开始就共享，因为业务逻辑总是随业务快速演化。
- 把远程模块地址当成生产配置管理：Module Federation 的远程地址如果散落在代码里，后期升级会很难收拾。最好收敛到环境配置或服务发现机制，并留好版本回退通道。
- 组合使用时，明确谁做主框架：通常推荐 single-spa 作为壳，Module Federation 负责壳和子应用之间的依赖协作。如果反过来，让 MF 承担页面生命周期，构建链路会变得非常重。
选型不是一次性的。先做路由级集成，再逐步引入模块共享，这种演进路径是可行的。反过来，如果你已经用 MF 做了大量组件共享，后续想加 single-spa 做应用隔离，成本也还在可控范围内。关键是要让子应用和共享模块的边界始终保持清晰。
说到底，single-spa 与 Module Federation 的选型，不存在绝对意义上的哪个更好。它们分别对应前端架构中应用集成层和模块供给层。真正的最佳选择，取决于你的组织规模、团队边界、技术栈一致性以及你能承受的长期维护成本。用一张决策树把这些条件摊开，远比直接抄某个成熟团队的方案更可靠。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/646/