產生背景：
在 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 一樣簡單。
