微前端四大方案选型对比与最佳实践：qiankun、micro-app、wujie、Module Federation

前言

微前端不是银弹，但在多团队、多系统、多技术栈并存的中后台场景里，它确实能降低整合成本。本文整理 qiankun、micro-app、wujie、Module Federation 四种常见方案的核心差异、适用场景和最佳实践，方便后续项目选型时快速对照。

一、四个方案的核心定位

方案	核心定位	技术原理
qiankun	微应用框架	基于 single-spa，JS 沙箱 + CSS 隔离
micro-app	微应用框架	基于 Web Components，标签式嵌入
wujie	微应用框架	iframe JS 隔离 + Web Components 样式隔离
Module Federation	模块共享机制	Webpack 5 / Vite 运行时模块联邦

前三个属于"微应用级"方案，适合把多个完整应用拼到一个平台；Module Federation 属于"模块级"方案，更适合组件、业务模块共享。

二、方案对比

维度	qiankun	micro-app	wujie	Module Federation
隔离性	中等，JS 沙箱 + CSS 隔离	中等，Web Components 隔离	强，iframe + Shadow DOM	无，依赖项目规范
接入成本	较高，需改生命周期和路由	较低，标签式接入	很低，子应用几乎零改造	高，需改造构建配置
多技术栈	好	好	好	一般，更适合同技术栈
Vite 支持	一般	较好	好	需插件支持
性能	较好	较好	内存占用偏高	最好
保活能力	有限	支持	强	不适用
生态成熟度	高	中	中	高
适用场景	存量系统整合	快速接入后台系统	强隔离、跨域、保活	组件/模块共享

三、各自优缺点

qiankun

优点：

社区成熟，案例多，问题可查性强；
沙箱、预加载、生命周期、通信机制完整；
多技术栈兼容较好。

缺点：

子应用需要改造生命周期、路由、public-path；
Vite 项目支持较弱；
多应用保活能力有限；
配置相对重。

micro-app

优点：

接入轻，主应用可用 <micro-app> 标签嵌入；
沙箱、通信、预加载、keep-alive 能力较完整；
对 Vite 项目更友好；
改造成本低于 qiankun。

缺点：

生态和案例少于 qiankun；
虚拟路由、组件化接入需要理解；
老旧全局脚本需要验证兼容性。

wujie

优点：

子应用改造成本极低，很多存量系统可直接接入；
iframe 物理隔离，JS 和 CSS 隔离能力最强；
支持保活、多应用同时激活；
对 Vite 项目友好。

缺点：

iframe 内存占用更高，保活模式下更明显；
调试需要在 iframe 上下文中排查；
跨域 iframe 下摄像头、定位、弹窗等能力可能受限；
社区案例相对少。

Module Federation

优点：

模块级共享，依赖复用好；
运行时性能高；
适合跨应用共享组件、页面模块；
可构建统一的业务组件共享层。

缺点：

不是完整微应用框架，缺少沙箱、路由治理、应用通信；
强依赖 Webpack / Vite 构建体系；
改造成本较高；
不适合作为整站微应用方案。

四、选型建议

场景	推荐方案
多技术栈存量系统整合	qiankun
Vue/React 后台快速整合	micro-app
强隔离、跨域接入、多应用保活	wujie
同技术栈组件/模块共享	Module Federation
多个独立后台拼到一个平台	micro-app / wujie
统一技术栈下共享业务组件	Module Federation

如果项目目标是"把多个现有后台拼到一个平台"，优先考虑 micro-app 或 wujie ；如果目标是"多个应用共享同一套业务组件"，再考虑 Module Federation。

五、最佳实践

1. 先明确边界

不要一上来就定方案，先确认：

是整站接入，还是组件共享？
子应用是否跨域？
是否需要保活？
是否需要多技术栈兼容？
子应用改造成本能接受多少？

2. 微应用方案优先控制改造成本

qiankun、micro-app、wujie 都属于微应用方案，重点要解决：

子应用路由前缀；
静态资源 public-path；
登录态同步；
主应用与子应用通信；
样式隔离；
全局变量污染。

其中 wujie 对存量系统最友好，qiankun 对成熟度要求高的项目更稳，micro-app 在接入成本和生态之间比较平衡。

3. Module Federation 适合做共享层

Module Federation 不建议直接拿来替代微应用框架。更合理的用法是：

把公共组件抽成 Remote；
把业务模块按边界暴露；
主应用和子应用共享 Vue、React 等基础依赖；
避免把强依赖路由、Store、登录态的组件暴露出去。

4. Vue 项目共享组件时注意单例

使用 Module Federation 共享 Vue 组件时，必须保证 Vue 是单例，否则容易出现：

响应式失效；
provide/inject 不可用；
Pinia/Vuex 状态不同步；
组件挂载异常。

建议在 shared 中配置：

ts 复制代码

shared: {
  vue: {
    singleton: true,
    requiredVersion: '^3.x'
  }
}

5. 组件尽量做纯 UI 化

跨应用共享的组件最好不要强依赖：

父应用路由；
父应用 Store；
父应用全局状态；
父应用特定样式。

更推荐通过 props、emit、事件总线或统一通信层传递数据。

6. 样式隔离要提前规划

qiankun / micro-app / wujie：建议子应用使用 scoped、CSS Modules 或命名空间前缀；
Module Federation：没有自动样式隔离，必须靠组件自身规范；
如果隔离要求很高，wujie 的 iframe + Shadow DOM 方案更省心。

7. 不要过度微前端化

如果只是一个单体后台，没必要上微前端。微前端更适合：

多个团队独立开发；
多个存量系统需要统一入口；
不同技术栈系统需要共存；
需要独立部署、独立升级；
需要共享部分业务模块。

六、总结

方案	一句话评价
qiankun	成熟稳，但改造成本高
micro-app	接入轻，适合 Vue/React 后台整合
wujie	隔离强、保活好，适合存量系统快速接入
Module Federation	模块共享利器，不适合直接替代微应用框架

实际落地时，可以把它们组合使用：用 micro-app / wujie 做微应用接入，用 Module Federation 做组件共享层。这样既能降低存量系统整合成本，又能逐步沉淀统一的业务组件体系。