微前端作为现代Web应用架构演进的重要方向,正在重塑大型前端应用的开发范式。微前端是借鉴了微服务的理念,将一个庞大的应用拆分成多个独立灵活的小型应用,每个应用都可以独立开发,独立运行,独立部署,还可以随意组合,这样就降低了耦合度,从而更加灵活。
一、微前端核心价值与演进历程
1.1 架构演进痛点
- 巨石应用困境:代码库膨胀、团队协作困难、技术升级受阻
- 微服务启示:借鉴后端微服务架构思想实现前端解耦
- 典型场景:中后台系统、多团队协作项目、渐进式重构
1.2 核心设计原则
- 技术栈无关:主框架不限制子应用技术选型
- 独立自治:独立开发、构建、部署、运行
- 渐进式升级:新旧系统平滑过渡
- 状态隔离:运行时环境隔离与通信可控
1.3 场景演示
- 后台管理系统
最外面一层可以当主应用,里面可以放不同的子应用子应用不受技术的限制。

- web商店(未来趋势)
例如一些导航网站,可以提供微前端的接入,我们的网站也可以入驻该网站,并且还可以提供一些API增加交互,有点类似于小程序。小程序可以调用微信的一些能力例如支付,扫码等,导航类型的网站也可以提供一些API,我们的网站接入之后提供API调用,可以实现更多有趣的玩法。

二、主流方案
基础方案对比
| 特性 | iframe | qiankun | EMP | 无界 |
|---|---|---|---|---|
| 隔离性 | ★★★★ | ★★★ | ★★ | ★★★★ |
| 通信效率 | ★★ | ★★★ | ★★★★ | ★★★★ |
| 保活支持 | ❌ | ❌ | ❌ | ✔️ |
| Vite支持 | ✔️ | ❌ | ✔️ | ✔️ |
| 接入成本 | 低 | 高 | 中 | 极低 |
1. iframe 方案
| 特点 | 不足 | 底层原理 | 适用场景 |
|---|---|---|---|
| ✅ 天然隔离性 | ❌ DOM割裂(弹窗/滚动条问题) | 浏览器原生iframe隔离机制 | 安全性要求高的简单页面集成 |
| ✅ 零改造接入 | ❌ 通信复杂(需postMessage) | 快速集成第三方独立应用 | |
| ✅ 多技术栈支持 | ❌ 路由状态丢失 | 无需深度交互的展示型模块 |
2. qiankun 方案
| 特点 | 不足 | 底层原理 | 适用场景 |
|---|---|---|---|
| ✅ HTML Entry降低改造成本 | ❌ 高适配成本(路由/资源路径) | JS沙箱:Proxy + with劫持全局变量 |
企业级中后台系统 |
| ✅ 渐进式沙箱机制 | ❌ 性能损耗(严格隔离模式) | CSS沙箱:Shadow DOM或属性隔离 | 需要严格隔离的复杂项目 |
| ✅ 静态资源预加载 | ❌ 不支持Vite/ES Module | 渐进式重构传统巨石应用 |
3. micro-app 方案
| 特点 | 不足 | 底层原理 | 适用场景 |
|---|---|---|---|
| ✅ WebComponent组件化接入 | ❌ CSS隔离不彻底(前缀方案) | JS沙箱:继承qiankun Proxy机制 | 多应用共存的管理平台 |
| ✅ 子应用保活支持 | ❌ 旧浏览器兼容性问题 | CSS沙箱:micro-app[name=xxx]选择器 |
技术栈统一的新项目 |
| ✅ 虚拟路由保留状态 | ❌ Vite需插件改造 | 需要动态加载子应用的导航系统 |
4. EMP 方案
| 特点 | 不足 | 底层原理 | 适用场景 |
|---|---|---|---|
| ✅ 去中心化模块共享 | ❌ 强pack 5 | Webpack Module Federation模块联邦 | 跨团队协作的模块化项目 |
| ✅ 跨框架组件复用 | ❌ 无运行时隔离 | 依赖共享与远程加载机制 | React/Vue混合技术栈项目 |
| ✅ 完美支持TypeScript | ❌ 路由可能冲突 | 需要共享通用组件库的场景 |
5. 无界微前端方案
| 特点 | 不足 | 底层原理 | 适用场景 |
|---|---|---|---|
| ✅ 4行代码极简接入 | ❌ 初始化延迟(iframe origin切换) | CSS隔离:Shadow DOM | 需要快速集成的Vite/React18项目 |
| ✅ 原生支持Vite | ❌ Axios需手动适配 | JS隔离:空白iframe沙箱 | 多应用保活的Dashboard系统 |
| ✅ 完美应用保活 | ❌ 通信性能损耗约5-10% | 通信机制:Proxy事件总线 | 高体验要求的后台管理系统 |
参考文章: