本文基于qiankun实现库来做一个知识整理以及落地实现。
什么是微前端
微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将Web应用由单一应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。 微前端不是单纯的前端框架或者工具，而是一套架构体系。
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently.
-- Micro Frontends
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
为什么使用微前端架构
任何新技术的产生都是为了解决现有场景和需求下的技术痛点，微前端也不例外：
- 拆分和细化
当下前端领域，单页面应用（SPA）是非常流行的项目形态之一，而随着时间的推移以及应用功能的丰富，单页应用变得不再单一而是越来越庞大也越来越难以维护，往往是改一处而动全身，由此带来的发版成本也越来越高。微前端的意义就是将这些庞大应用进行拆分，并随之解耦，每个部分可以单独进行维护和部署，提升效率。
- 整合历史系统
在不少的业务中，或多或少会存在一些历史项目，这些项目大多以采用老框架的B端管理系统为主，介于日常运营，这些系统需要结合到新框架中来使用还不能抛弃，对此我们也没有理由浪费时间和精力重写旧的逻辑。而微前端可以将这些系统进行整合，在基本不修改来逻辑的同时来同时兼容新老两套系统并行运行。
微前端架构的核心价值
- 技术栈无关
主框架不限制接入应用的技术栈，微应用具备完全自主权。
- 独立开发、独立部署
微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新，可以接入自动化部署等开发流程。
- 增量升级
在面对各种复杂场景时，利用微前端架构对项目进行增量升级，而不是对一个已经存在的项目进行全量的技术栈升级或者重构。
- 独立运行
每一个微应用在运行过程中，状态隔离，不共享，但是可以使用通讯方式进行数据交换。
为什么选择微前端而不是iframe
如果不考虑体验问题，那么iframe将是一个几乎完美的微前端解决方案。
iframe提供了浏览器原生的硬隔离方案，不论是样式隔离、js隔离这类问题都能被完美的解决，但是它最大的问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享。随之带来的是开发体验与产品体验的问题。
- url不同步，浏览器刷新iframe url状态丢失、后退前进按钮无法使用。
- UI不同步，DOM结构不共享。
举个例子，我们在微应用中使用了antd组件库中的Model组件，如果使用iframe嵌入屏幕右下角1/4处，那么在完整项目使用时，你会发现弹窗并没有在页面的中间，而是在iframe嵌入的中间，这将会非常影响页面效果。
-
全局上下文完全隔离，内存变了不共享。iframe内外系统的通信。数据同步等需求
-
加载时间长。 每次子应用进入都是一次浏览器上下文的重建、资源重新加载的过程。
综上，iframe只能算是一个解决方案，但是如果有更好的微前端框架那为啥不用呢。
