微前端
实习过程中，做了些微前端方向的调研，记录下
微前端将前端拆分为独立的可以单独运行，测试，部署的代码， 具有技术栈无关，多团队，多业务线协作的特点。
前端现有的页面，分为单页应用和多页应用，各有优劣， spa单页 通信方便，前进后退对用户的感知友好。提前预加载等性能优化措施。mpa将系统分为多个仓库维护，在首页聚合所有平台的入口
iframe 在微前端框架流行前， 是一种非常好的解决方案，这是浏览器的原生的隔离方案，主要是样式隔离，js隔离等等问题都能被轻松的解决到。但是隔离性无法突破，导致应用上下文之间无法被共享。 主要涉及 路由不同步，刷新， 前进后退的失效，dom割裂，通信困难， 白屏事件，并且并非一个文档上下文，那么对于事件的冒泡捕获等等就会有影响。预加载，共享组件库等问题。
还可以通过发npm包来实现，通过npm包的形式引入，当公共组件升级，那么项目要宠幸升级上线。
这种方式也丧失了动态下发代码的能力。
模块联邦的方式，主要是EMP，欢聚时代，我尝试的时候，对于已有项目的接入不太友好。一种远程模块动态加载，运行技术。允许将当前构建的应用作为容器应用，异步加载远程模块，允许将原本的单个应用按照理想的方式拆分，然后进行加载。
但是缺少沙箱隔离，可能会导致js变量污染。缺乏css隔离， 版本控制，需要显示配置路径，版本控制存在和npm一样的缺点。
尽管iframe存在问题，但是可以借助其思想。 iframe 加载文档，1. 文档加载，2. html渲染，3. JavaScript执行，4. JS隔离。
spa的微前端架构，从设计层面上是基座和子应用分治。基座进行注册，并下发信息，子应用收到信息后，进行渲染。
考虑
1， 应用加载， 在应用没有被激活之前，需要考虑应用层面对不同标准的应用的时候，框架需要的加载策略是不同的，js bundle 和umd规范的标准。fetch script标签的能力，但是对于esm 的标准，需要使用动态import的方式。 设计预加载，html入口，拆分dom style script js入口， 解析子应用
2. 应用调度， 提供子应用的声明周期
3. 沙箱隔离 收集副作用， 多个实例收集副作用
4. 路由系统 不用应用路由不同步， 不用应用对路由的响应 路由劫持系统
5. 应用通信
副作用
- html中包含，script style link
- 动态副作用 动态创建的style ，link dom， 添加全局变量， 添加定时器，网络请求，localstorage 等对当前页面产生影响的内容
隔离
快照沙箱
通过快照的方式来保存当前的执行环境，在应用销毁后，回退到之前的执行环境
css样式隔离方案
css模块化， 通过import方式来引入样式
样式约定以及工程化， 各个子应用都约定自己的特有前缀
shadow dom
完全解决了样式隔离，游离在dom树之外的shadow dom， 将dom和css隔离开来，但是由于浏览器的兼容问题， 可靠性得考虑
Web components 的一个重要属性是封装——可以将标记结构、样式和行为隐藏起来，并与页面上的其他代码相隔离，保证不同的部分不会混在一起，可使代码更加干净、整洁。其中，Shadow DOM 接口是关键所在，它可以将一个隐藏的、独立的 DOM 附加到一个元素上。
css in js
动态加载卸载样式表