一、痛点
后端使用微服务架构来解耦服务间依赖，而前端需要聚合
微前端是将多个小型前端应用聚合为一的应用。
微前端的核心目标：将巨石应用拆解成若干可以自治的松耦合微应用，使微应用真正具备独立开发、独立运行的能力，使部署、管理和服务功能交付变得更加简单
二、使用iframe的解决方案
每个业务节点使用iframe嵌套在平台内，天然的隔离
1.iframe的url在刷新时参数丢失 -> 可以在平台打开每一个业务节点时，将路由信息记录在session中
2.dom结构不共享，业务节点的遮罩层不能覆盖全部 -> 使用平台在window上挂载一个方法，需要时调用平台方法
3.完全隔离 -> 主应用的cookie要透传到根域名的不同子应用中实现免登效果
4.慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程
二、single-spa
注册所有app,当url有变化时，找到对应的子应用，再执行生命周期 子应用会导出bootstrap,mount,unmount三个生命周期
三、qiankun的基础原理
基于single-spa进行二次开发
1.js隔离机制-沙箱
🔔快照沙箱SnapshotSandbox
使用windowShapshot和modifyPropsMap两个对象
沙箱激活-微应用处于运行时：记录当前window的状态，恢复上一次失活时window的状态
沙箱失活：记录window上哪些状态发生了变化，恢复
⛔️重要问题：改变全局window，污染；若同时多个微应用必然混乱，不能支持
🔔支持单应用的代理沙箱LegacySandbox
把对象改为map的数据结构，解决for(props in window)遍历的开销
🔔支持多应用的代理沙箱ProxySandbox
不再使用window，不用恢复逻辑也不需要记录属性值的变化
将window上所有属性值拷贝成一个新的fakeWindow对象，之后使用proxy代理这个对象，将用户的操作全部拦截下来
this.proxyWindow = new Proxy(fakeWindow,{set,get})
使用时proxySandBox1.proxyWindow.aa = '1'
2.css样式隔离
shadowDom样式沙箱，qiankun会先创建一个空div，设置id、data-name、data-version等属性，保证template转换成dom节点后跟节点只有一个
但是如果一些弹窗，直接挂载在body上，即元素瓜子啊到了shadowdom外部，是不行的，需要采取措施规避
影子dom相当于dom中的dom，实际上是在浏览器渲染文档的时候会给指定的dom架构插入编写好的dom元素，但是插入的shadowDom与主文档的dom保持分离 shadowDom封装出来的dom元素是独立的，外部配置不会影响到内部
四、无界
iframe+web component
在底层选用proxy+Object.defineproperty的方法将js-iframe中对dom操作代理到webcomponent shadowRoot容器中
1.创建一个iframe插入主应用
2.停止iframe的加载，如果src设置为主应用的域名会请求资源失败，要修改请求域名为子应用的真实域名
3.解析子应用入口html，创建webcomponent并挂载在html
4.创建script标签插入到iframe中
5.劫持document，改为从shadowRoot里面查找
