2、主流方案对比：iframe、Web Components、Module Federation、qiankun、Micro-app 对比
说实话，微前端这个概念火了这几年，方案多得让人眼花缭乱。
我经常被问到：「到底该选哪个？」
其实没有银弹。每个方案都有自己的脾气。今天我就把主流的五个方案拉出来遛遛，说说我的真实感受。
2.1 iframe：最老实的方案
iframe 是最原始的方式。每个子应用就是一个独立的 iframe 标签。
优点很明显：
- 隔离性极强 —— 样式、脚本、全局变量，谁也影响不了谁
- 部署简单 —— 子应用完全独立，想怎么改就怎么改
- 兼容性好 —— 所有浏览器都支持，没有黑魔法
但坑也不少。我在项目中遇到过一个问题：用户登录后，在 iframe 里操作完，父页面根本不知道。还得靠 postMessage 来回传消息，维护起来特别累。
iframe 适合什么场景？
- 第三方不可控的内容（比如嵌入其他公司的页面）
- 对隔离性要求极高的场景
- 快速原型验证
2.2 Web Components：标准化的尝试
Web Components 是浏览器原生支持的组件化方案。它用 Custom Elements、Shadow DOM 和 HTML Templates 来实现隔离。
说白了，就是浏览器帮你把样式和 DOM 封装起来。外面再怎么改，也影响不到里面。
我试过用 Web Components 做微前端。嗯，怎么说呢……
优点：
- 原生支持，不需要额外框架
- Shadow DOM 提供天然的样式隔离
- 可以跨框架使用（React 里用 Vue 组件，反过来也行）
缺点也很明显：
- Shadow DOM 的穿透问题 —— 有时候你想让子应用继承父主题，反而很麻烦
- 浏览器兼容性 —— 老版本 IE 直接歇菜
- 生态不成熟 —— 很多 UI 库对 Web Components 支持不好
2.3 Module Federation：Webpack 5 的杀手锏
Module Federation 是 Webpack 5 推出的功能。它让多个独立构建的应用可以在运行时共享模块。
你想想看，以前我们做微前端，要么用 iframe 隔离，要么用路由分发。Module Federation 的思路完全不同 —— 它让应用之间可以直接引用对方的代码。
举个例子：
// 子应用 A 暴露组件
new ModuleFederationPlugin({
name: 'app_a',
filename: 'remoteEntry.js',
exposes: {
'./Header': './src/components/Header',
},
})
// 主应用引用
const Header = React.lazy(() => import('app_a/Header'));我在一个大型电商项目中用过这个方案。当时有十几个团队并行开发，每个团队维护自己的模块。Module Federation 让我们做到了「独立部署、运行时组合」。用户体验非常好，因为切换子应用几乎没有感知。
但要注意：
- 所有应用必须用 Webpack 5
- 版本管理要小心 —— 我遇到过因为依赖版本不一致导致的运行时错误
- 调试起来比较麻烦，因为代码是运行时加载的
2.4 qiankun：蚂蚁出品，必属精品
qiankun 是基于 single-spa 的微前端框架。它把 single-spa 的复杂配置封装了起来，提供了开箱即用的体验。
说白了，qiankun 就是帮你管理子应用的生命周期 —— 加载、挂载、卸载、更新。你只需要配置一下子应用的入口地址就行。
我最早接触微前端就是用的 qiankun。当时公司要把三个老项目整合到一起，每个项目技术栈都不一样（一个 Vue2、一个 React、一个 jQuery）。qiankun 居然都能接进来，确实省了不少事。
优点：
- 接入成本低 —— 改几行代码就能跑起来
- 支持多种技术栈 —— Vue、React、Angular、甚至 jQuery
- 社区活跃 —— 遇到问题基本都能搜到答案
缺点：
- 样式隔离依赖约定 —— 不是 100% 可靠
- JS 沙箱有性能开销 —— 子应用多了会卡
- 对子应用有侵入性 —— 需要修改子应用的打包配置
2.5 Micro-app：京东出品，后来居上
Micro-app 是京东开源的一款微前端框架。它的思路很有意思 —— 用 Web Components 的思路来做微前端，但底层还是用 JS 实现的。
你使用起来就像写一个普通的 HTML 标签：
<micro-app name="app1" url="http://localhost:3001/"></micro-app>是不是很简洁？
我最近在一个新项目中尝试了 Micro-app。说实话，体验比 qiankun 好不少：
- 接入更简单 —— 不需要改子应用的打包配置
- 样式隔离更彻底 —— 基于 Shadow DOM 的思路，但兼容性更好
- 性能更好 —— 沙箱机制更轻量
但也不是完美的：
- 社区还在成长 —— 遇到冷门问题可能搜不到答案
- 对某些框架支持不够好 —— 比如 Svelte 的兼容性还在完善中
- 文档有些地方写得不清楚 —— 我踩过几个坑都是看源码才搞明白的
2.6 横向对比：一张表说清楚
| 维度 | iframe | Web Components | Module Federation | qiankun | Micro-app |
|---|---|---|---|---|---|
| 接入成本 | 低 | 中 | 高 | 低 | 低 |
| 样式隔离 | 完美 | 好 | 无 | 一般 | 好 |
| JS 隔离 | 完美 | 好 | 无 | 一般 | 好 |
| 性能 | 差 | 中 | 好 | 中 | 好 |
| 多技术栈支持 | 好 | 好 | 差 | 好 | 好 |
| 社区活跃度 | 高 | 中 | 高 | 高 | 中 |
| 学习成本 | 低 | 中 | 高 | 低 | 低 |
| 适合场景 | 简单嵌入 | 标准化组件 | 同技术栈 | 快速落地 | 新项目 |
2.7 我的选择建议
说了这么多，到底怎么选？
我个人习惯这样判断：
- 如果只是简单嵌入第三方页面 —— 用 iframe，别折腾
- 如果团队技术栈统一，追求极致性能 —— 选 Module Federation
- 如果项目紧急，需要快速落地 —— 选 qiankun，文档多，坑少
- 如果从零开始，想用最新的方案 —— 选 Micro-app，体验确实好
- 如果对标准化有执念 —— 可以研究 Web Components，但要做好踩坑的准备
下一章，我会详细讲讲 qiankun 的落地实践。包括怎么接入、怎么处理样式隔离、怎么优化性能。到时候我会把我在项目中踩过的坑都抖出来，保证干货满满。