目录
[1. 前言](#1. 前言)
[2. 社区常用微前端框架对比](#2. 社区常用微前端框架对比)
[3. 框架具体改造落地](#3. 框架具体改造落地)
[3.1 Qiankun](#3.1 Qiankun)
[3.2 Micro App](#3.2 Micro App)
[3.3 wujie-micro](#3.3 wujie-micro)
[4. 当然具体落地过程中也会遇到一些问题](#4. 当然具体落地过程中也会遇到一些问题)
1. 前言
微前端架构具备以下几个核心价值：
- 技术栈无关 主框架不限制接入应用的技术栈，微应用具备完全自主权
- 独立开发、独立部署 微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
- 增量升级 在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
- 独立运行时 每个微应用之间状态隔离，运行时状态不共享
构建一个稳健的微前端项目，一般不考虑直接用iframe。 可以阅读 Why Not Iframe ?
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题
2. 社区常用微前端框架对比
调研市面微前端的方案，从技术角度可以主要分为：single-spa、WebComponent。接下来，将从上手难度到原型环境做对比。
代表框架：
蚂蚁金服团队
qiankunhttps://qiankun.umijs.org/zh/guide京东零售团队
micro-apphttps://micro-zoe.github.io/micro-app/腾讯无极低代码团队
wujie-microhttps://wujie-micro.github.io/doc/
| 对比点 | qiankun | Micro App | wujie-micro |
|---|---|---|---|
| 类型 | single-spa | 类WebComponent | WebComponent + iframe |
| 首个版本 | v1.1.4 (2019-08-01) | v0.1.0 (2021-07-09) | 1.0.0-rc.1 (2022-07-05) |
| 最近更新 | v2.10.8 (2023-05-17) | v1.0.0-beta.4 (2023-04-27) | 1.0.16 (2023-05-17) |
| ie支持 | Yes | ==No== | Yes，自动切换成iframe |
| 框架体积 | 94kb | 30kb | 78kb |
| 数据通信机制 | props | addDataListener | props、window、eventBus |
| 接入成本 | 中 | 低 | 低 |
| 开箱即用 | ==No== | ==No== | Yes |
| JS沙箱 | Yes | Yes | Yes，iframe来实现js沙箱 |
| 样式隔离 | Yes | Yes | Yes，webcomponent来实现页面的样式元素隔离 |
| 元素隔离 | ==No== | Yes | Yes |
| 静态资源地址补全 | ==No== | Yes | Yes |
| 预加载 | Yes | Yes | Yes |
| keep-alive | ==No== | Yes | Yes |
| 应用共享同一个资源 | Yes | Yes | Yes |
| 应用嵌套 | Yes | Yes | Yes |
| 插件系统 | ==No== | Yes | Yes |
| 子应用不改造接入 | ==No== | ==No== | Yes，满足跨域可以不改 |
| 内置降级兼容处理 | ==No== | ==No== | Yes，通过 babel 来添加 polyfill |
3. 框架具体改造落地
以我自己的项目项目现状为例：
主项目：react17 + webpack5 + antd + hash路由
子项目：vue3.0 + vite2 + element-plus + history路由
3.1 Qiankun
使用了比single-spa更完整的import-html-entry方案，主要思路是允许以html文件为应用入口，然后通过一个html解析器从文件中提取js和css依赖，并通过fetch下载依赖
子项目使用的是vite，而qiankun目前是不支持vite的，需要借助插件完成，实现起来会有一定的调试难度和问题；
主应用需要修改webpack配置，子应用需要处理微前端模式下的baseUrl
主应用是hash模式，子应用也要对应改为hash模式，才能正常匹配路径
3.2 Micro App
核心功能在CustomElement基础上进行构建，CustomElement用于创建自定义标签，并提供了元素的渲染、卸载、属性修改等钩子函数，我们通过钩子函数获知微应用的渲染时机，并将自定义标签作为容器，微应用的所有元素和样式作用域都无法逃离容器边界，从而形成一个封闭的环境。
主项目是hash，子项目是history，为了浏览器地址栏的无痕接入（不出现?xxx）需要将子项目的路由模式改成hash，也需要处理子项目中微前端模式下的baseUrl
子项目使用了element-plus，在引入micro-app后，子项目的dialog，popup等弹框类组件无法正常展示，报错信息如下，需要对源码做一点修改才能处理
3.3 wujie-micro
将子应用的 js 注入主应用同域的 iframe 中运行，iframe 是一个原生的 window 沙箱，内部有完整的 history 和 location 接口，子应用 Js 实例运行在 iframe 中，路由彻底和主应用解耦。
创建一个 Web Component 自定义元素，然后将子应用的 Dom 渲染在这个自定义元素内部，以达到样式隔离的目的。
通过代理 iframe 的 document 到 Web Component 自定义元素，这样在 iframe 内执行类似 getElementById、querySelector 这样的操作就是在操作 Web Component 自定义元素内的 Dom 了
只需要在主项目中添加子项目入口，简单配置；子项目不需要做任何处理，vite天然支持资源跨域，只需要注意主应用访问子应用的跨域问题即可
综上，我们选择使用wujie，能保证接入破坏力最小，不需要对子应用做任何处理；主应用的改造也很简单。