微前端作为现代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事件总线 |
高体验要求的后台管理系统 |
参考文章:
juejin.cn/post/721260...
juejin.cn/post/712564...