微前端就是将不同的功能按照不同的维度拆分成多个子应用。通过主应用来加载这些子应用。微前端的核心在于拆，拆完后在合！
我们可以将一个应用划分成若干个子应用，将子应用打包成一个个的 lib 。当路径切换 时加载不同的子应用。这样每个子应用都是独立的，技术栈也不用做限制了！从而解决了前端协同开发问题。
文档地址： https://qiankun.umijs.org/zh
2018 年 Single-SPA 诞生了， single-spa 是一个用于前端微服务化的 JavaScript 前端解决方案 ( 本身没有处理样式隔离， js 执行隔离 ) 实现了路由劫持和应用加载。
2019 年 qiankun 基于 Single-SPA, 提供了更加开箱即用的 API （ single-spa + sandbox + import-html-entry ） 做到了，技术栈无关、并且接入简单（像 i frame 一样简单）。
这里我们打算建立三个项目进行实操，一个Vue项目充当主应用，另一个Vue和React应用充当子应用
基座：qiankun-base 子应用：qiankun-vue、qiankun-react
react + react-router 技术栈的主应用：只需要让子应用的 activeRule 包含主应用的这个路由即可。
vue + vue-router 技术栈的主应用:
用绝对路径，不用用相对路径，例如
qiankun 只能解决子项目之间的样式相互污染，不能解决子项目的样式污染主项目的样式
冲突的样式，采用BEM命名方式
子应用，需要增加 update 钩子以便主应用手动更新微应用
主应用，直接调用子应用实例的 update 方法即可
在 toB 的前端开发工作中，我们往往就会遇到如下困境：
基座模式
通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案也是蛮多的。
注册表模式
和微服务架构相似，不论是哪种微前端方式，都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口，即路由。
它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。
作用：
应用注册。即提供新的微前端应用，向应用注册表注册功能。
应用发现。让主应用可以寻找到其它应用。
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
微前端每个应用都拥有自己的生命周期：
bootstrap， 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。
Mount，应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法
Unload，删除应用的生命周期
Unmount，应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例
乾坤，作为一款微前端领域的知名框架，其建立在single-spa基础上。相较于single-spa，乾坤做了两件重要的事情，其一是加载资源，第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test，这个属性只能在 A 应用自己的作用域通过 window.test 获取到，主应用或者其他应用都无法拿到这个变量。
1、快照沙箱
2、支持多应用的代理沙箱
