产生背景：
在 toB 的前端开发工作中，我们往往就会遇到如下困境：
工程越来越大，打包越来越慢
团队人员多，产品功能复杂，代码冲突频繁、影响面大
技术栈单一，无法灵活扩展
微前端到底是什么？
定义：单个复杂应用分解成由一个主应用和多个子应用聚合而成的系统。通过主应用来加载子应用，而子应用由不同的功能按照不同的维度拆分而来。各个子应用可以独立开发、独立部署。
微前端架构模式？
基座模式
通过一个主应用，来管理其它应用。设计难度小，方便实践，但是通用度低。
自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
就当前而言，基座模式实施起来比较方便，方案也是蛮多的。
注册表模式
和微服务架构相似，不论是哪种微前端方式，都需要有一个应用注册表的服务。这个应用注册表拥有每个应用及对应的入口，即路由。
它可以是一个固定值的配置文件，如 JSON 文件，又或者是一个可动态更新的配置，又或者是一种动态的服务。
作用：
应用注册。即提供新的微前端应用，向应用注册表注册功能。
应用发现。让主应用可以寻找到其它应用。
Qiankun
首先看一下它的用法：
https://qiankun.umijs.org/zh/guide/getting-started
生命周期
微前端每个应用都拥有自己的生命周期：
bootstrap， 只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。 通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。
Mount，应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法
Unload，删除应用的生命周期
Unmount，应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例
乾坤有哪些特性？
乾坤，作为一款微前端领域的知名框架，其建立在single-spa基础上。相较于single-spa，乾坤做了两件重要的事情，其一是加载资源，第二是进行资源隔离。而资源隔离又分为Js资源隔离和css资源隔离.
css隔离，确保微应用之间样式互相不干扰。
JS沙箱，确保微应用之间 全局变量/事件 不冲突。
每个微应用对全局的影响都会局限在微应用自己的作用域内。比如 A 应用在 window 上新增了个属性 test，这个属性只能在 A 应用自己的作用域通过 window.test 获取到，主应用或者其他应用都无法拿到这个变量。
乾坤Js隔离机制（沙箱）的发展史
1、快照沙箱
const window = {};
class SnapshotSandbox {
windowSnapshot = {}; // 保存window快照
modifyPropsMap = {}; // 修改的内容
// 沙箱激活
active() {
// 记录window当时的状态
for (const prop in window) {
this.windowSnapshot[prop] = window[prop];
}
// 恢复上一次沙箱失活时记录的沙箱运行过程中对window做的状态改变，也就是上一次沙箱激活后对
window做了哪些改变，现在也保持一样的改变。
Object.keys(this.modifyPropsMap).forEach(prop => {
window[prop] = this.modifyPropsMap[prop];
})
} // 沙箱失活
inactive() {
for (const prop in window) {
if (window[prop] !== this.windowSnapshot[prop]) {
// 保存运行期间的修改
this.modifyPropsMap[prop] = window[prop];
// 恢复激活时的快照状态
window[prop] = this.windowSnapshot[prop];
}
}
}}
2、支持多应用的代理沙箱
class ProxySandbox {
proxyWindow;
isRunning = false;
active() {
this.isRunning = true;
}
inactive() {
this.isRunning = false;
}
constructor() {
const fakeWindow = Object.create(null);
this.proxyWindow = new Proxy(fakeWindow, {
set: (target, prop, value, receiver) => {
if (this.isRunning) {
target[prop] = value;
}
},
get: (target, prop, receiver) => {
return prop in target ? target[prop] : window[prop];
}
});
}}
// 验证：
let proxySandBox1 = new ProxySandBox();
let proxySandBox2 = new ProxySandBox();
proxySandBox1.active();
proxySandBox2.active();
proxySandBox1.proxyWindow.city = 'Beijing';
proxySandBox2.proxyWindow.city = 'Shanghai';
console.log('active:proxySandBox1:window.city:', proxySandBox1.proxyWindow.city);
console.log('active:proxySandBox2:window.city:', proxySandBox2.proxyWindow.city);
console.log('window:window.city:', window.city);
proxySandBox1.inactive();
proxySandBox2.inactive();
console.log('inactive:proxySandBox1:window.city:', proxySandBox1.proxyWindow.city);
console.log('inactive:proxySandBox2:window.city:', proxySandBox2.proxyWindow.city);
console.log('window:window.city:', window.city);
// ProxySandbox，完全不存在状态恢复的逻辑，同时也不需要记录属性值的变化，因为所有的变化都是沙箱内部的变化，和window没有关系，window上的属性至始至终都没有受到过影响。
HTML Entry 接入方式，让你接入微应用像使用 iframe 一样简单。
JS Entry是什么？？
在使用 single-spa 加载微应用时，我们加载的不是微应用本身，而是微应用导出的 JS 文件，即JS Entry。
要接入一个微应用，就需要对微应用进行一系列的改造，然而 JS Entry 的问题就出在这儿，改造时对微应用的侵入行太强，而且和主应用的耦合性太强。
微应用改造一般分为三步：
l 微应用路由改造，添加一个特定的前缀
l 微应用入口改造，挂载点变更和生命周期函数导出
在js文件的入口中会导出一个对象，这个对象上有 bootstrap、mount、unmount 这三个接入 single-spa 框架必须提供的生命周期方法，其中 mount 方法规定了微应用应该怎么挂载到主应用提供的容器节点上。
l 打包工具配置更改
侵入型强其实说的就是第三点，更改打包工具的配置，使用 single-spa 接入微应用需要将微应用整个打包成一个 JS 文件，发布到静态资源服务器，然后在主应用中配置该 JS 文件的地址告诉 single-spa 去这个地址加载微应用。这就导致常见的打包优化基本上都没了，比如：按需加载、首屏资源加载优化、css 独立打包等优化措施。
项目发布以后出现了 bug ，修复之后需要更新上线，为了清除浏览器缓存带来的应用，一般文件名会带上 chunkcontent，微应用发布之后文件名都会发生变化，这时候还需要更新主应用中微应用配置，然后重新编译主应用然后发布，这套操作简直是不能忍受的。这也是 微前端框架 之 single-spa 从入门到精通 这篇文章中示例项目中微应用发布时的环境配置选择 development 的原因。
qiankun 框架为了解决 JS Entry 的问题，于是采用了 HTML Entry 的方式，让用户接入微应用就像使用 iframe 一样简单。
DEMO：
https://github.com/sy-l123/qiankun-demo