常见微前端解决方案对比
痛点：JS沙箱隔离、CSS样式隔离、跨应用通信
样式隔离方案：严格的命名约定、CSS Module、CSS In JS库、shadow DOM 沙箱隔离办法：沙箱快照、Proxy代理 跨应用通信：使用自定义事件通信、全局Store、发布订阅
iframe及自定义消息传递机制
- 优点：实现简单（自带沙箱天然隔离）、技术不限制、消息传递（同源可以使用postMessage）
- 缺点：无SEO、URL状态不同步（url状态信息不能同步到父窗口，无法使用浏览器的前进后退）、DOM结构不共享（无法全局弹窗）、全局上下文完全隔离，每次进入都经历浏览器上下文重建、资源重新加载的过程
纯Web Components构建应用
- 优点：拥有自己独立的Scripts和Styles、代码的可读性清晰、组件资源内部高内聚自身控制资源加载
- 缺点：浏览器支持不够需要polyfill、重写现有应用转成Web Components
Module Federation 模块联邦
- 优点：开箱即用、独立开发部署、去中心化（模块共享不使用中心基座）、组件共享
- 缺点：无法沙箱隔离、仅限webpack5以上
组合式应用路由分发（中心基座方案）
基座应用大多数是一个前端SPA项目，主要负责应用注册，路由映射，消息下发 等，而微应用是独立前端项目。每个微应用注册到基座应用中，由基座进行管理，但是如果脱离基座也是可以单独访问
- 优点：技术不限制、无感切换、利于SEO、独立开发与部署
- 缺点：沙箱不隔离（ js 与 css 样式会出现冲突）
自由框架组合模式（复合型）
1、就好比完美解决沙箱隔离的 qiankun.js 就是基于 中心基座方案去做的一个升级； 2、还有比较完美的框架如：micro-app、EMP微前端等框架都是采取了以上的一种或多种方案的组合；
框架对比
| 框架 | 优点 | 缺点 |
|---|---|---|
| Single-spa | 技术栈无关、增量独立开发部署 | 无通信机制、不支持js沙箱、样式冲突、无法预加载 |
| Qiankun | html entry接入，像iframe简单。资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度 | 对eval安全性能的争议 |
| Micro App | 基于Web Component配置简单，qiankun的优势都有 | 改写现有组件 |
| EMP | 基于webpack5模块联邦，共享模块粒度灵活，共享依赖 | 需要统一webpack5，无法多框架兼容 |
