微前端介绍

微前端作为现代Web应用架构演进的重要方向，正在重塑大型前端应用的开发范式。微前端是借鉴了微服务的理念，将一个庞大的应用拆分成多个独立灵活的小型应用，每个应用都可以独立开发，独立运行，独立部署，还可以随意组合，这样就降低了耦合度，从而更加灵活。

一、微前端核心价值与演进历程

1.1 架构演进痛点

• ​巨石应用困境​：代码库膨胀、团队协作困难、技术升级受阻
• ​微服务启示​：借鉴后端微服务架构思想实现前端解耦
• ​典型场景​：中后台系统、多团队协作项目、渐进式重构

1.2 核心设计原则

• ​技术栈无关​：主框架不限制子应用技术选型
• ​独立自治​：独立开发、构建、部署、运行
• ​渐进式升级​：新旧系统平滑过渡
• ​状态隔离​：运行时环境隔离与通信可控

1.3 场景演示

1. 后台管理系统

最外面一层可以当主应用，里面可以放不同的子应用子应用不受技术的限制。

2. 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...