微前端
关键问题
1 子应用如何定义和使用？
2 如何动态加载？
3 如何隔离？
js
沙箱 sandbox proxy
快照砂箱，单子应用
css
shadow DOM
前缀约定式隔离CSS module
子应用加载添加、卸载移除
single-SPA
解决问题 1
兼容各种技术栈
更优的性能
每个独立模块的代码可做到按需加载,不浪费额外资源
无需重构现有代码
每个独立模块可独立运行
qiankun
解决问题 1-2-3
根据约定，子应用需要暴露声明周期方法，Qiankun 会去加载资源然后根据约定拿到方法，这里官方的推荐是通过 webpack 的 umd 输出格式来做
在执行 js 资源时通过 eval，会将 window 绑定到一个 Proxy 对象上，以防污染全局变量，并方便对脚本的 window 相关操作做劫持处理，达到子应用之间的脚本隔离
鲸落
为啥选用自己鲸落？ qiankun不满足吗？
做了哪些定制需求？
实现方式
- iframe
- nginx配置（前后端不分离）
- 微前端
优点- 纯前端解决方案
- 可以使用多种技术栈
- 完善的生态
缺点 - 上手成本高
- 需要改造现有应用
- 跨应用的联调变得复杂
why not iframe？
为什么不用 iframe，这几乎是所有微前端方案第一个会被 challenge 的问题。但是大部分微前端方案又不约而同放弃了 iframe 方案，自然是有原因的，并不是为了 "炫技" 或者刻意追求 "特立独行"。
如果不考虑体验问题，iframe 几乎是最完美的微前端解决方案了
iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。
其实这个问题之前这篇也提到过，这里再单独拿出来回顾一下好了。
- url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
- UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
- 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
- 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。
其中有的问题比较好解决(问题1)，有的问题我们可以睁一只眼闭一只眼(问题4)，但有的问题我们则很难解决(问题3)甚至无法解决(问题2)，而这些无法解决的问题恰恰又会给产品带来非常严重的体验问题， 最终导致我们舍弃了 iframe 方案。
