微前端：乾坤 VS 无界
共同点： 当路由切换的时候，可以去加载对应应用的代码，让其跑在容器里。
- 具备加载和卸载子应用的能力，页面从一个子应用切换到另一个子应用时，能正常进行加载和渲染；
- 具有路由状态保持能力，激活子应用后，浏览器刷新、前进、后退子应用的路由都可以正常工作；
- 主应用和子应用、子应用和子应用之间可以相互进行通信；
- 每个微应用都可独立仓库管理，独立技术栈开发、独立部署、独立运行；
single-spa方案，使用function + proxy + with实现，无界是基于WebComponent + iframe来实现。1、应用加载机制
| 框架 | 特点 |
| 乾坤 | 首先基于single-spa注册子应用，然后通过import-html-entry获取子应用的相关资源并对这些资源进行加工，随后构造和执行一些生命周期中需要执行的方法，并返回一个函数，该函数的返回值是一个包括了子应用生命周期方法的对象 |
| 无界 | 无需注册，直接将子应用注入主应用同域的iframe中运行 |
2、沙箱隔离机制
| 框架 | 特点 |
| 乾坤 | js隔离机制： SnapshotSandbox、LegacySandbox、ProxySandboxcss隔离机制： strictStyleIsolation、experimentalStyleIsolation |
| 无界 | js通过iframe来隔离，css通过webcomponent + shadowdom来隔离 |
3、路由保持机制
| 框架 | 特点 |
| 乾坤 | 通过props实现全局路由数据的存储及共享 |
| 无界 | 浏览器的前进后退可以不作任何处理直接作用于子应用，通过监听iframe的路由变化可以将子应用的url同步到主应用 |
4、应用通信机制
| 框架 | 特点 |
| 乾坤 | 通过发布订阅模式来实现通信，状态和回调处理函数全局统一维护，全局状态发生变化时触发各个应用注册的回调函数执行，将新旧状态传递到所有应用 |
| 无界 | 提供多种通信方式：window.parent直接通信、props数据注入、去中心化EventBus通信机制 |
5、优点和不足
| 框架 | 优点 | 不足 |
| 乾坤 | 能监听路由自动加载和卸载当前路由对应的子应用； 具有完备沙箱方案来隔离js和css； 支持静态资源预加载； 应用间通信简单； |
基于路由匹配，无法同时激活多个子应用，也不支持子应用保活； 改造成本较大，从 webpack、代码、路由等都要做一系列的适配； css 沙箱无法绝对的隔离，js 沙箱在某些场景下执行性能下降严重； 无法支持 vite 等 ES Module 脚本运行； |
| 无界 | 具备qiankun的所有优点，另外还具有以下优点： 主应用使用成本及子应用适配成本低； css沙箱和js沙箱都采用了原生隔离，无需担心污染问题； 支持路由保活和共享依赖； 具有强大插件系统，方便在运行时修改子应用代码； |
目前还比较新， 社区不够活跃 |
