微前端 ：微前端是一种软件架构模式 ，旨在解决大型前端应用程序开发和维护中的复杂性问题。它将前端应用程序拆分成更小的、独立的部分 ，每个部分可以由不同的团队开发、测试、部署和维护。这些独立的部分可以是单独的应用程序或者功能模块，它们可以独立开发和部署，但最终集成到一个统一的用户界面中。
微前端架构的优势包括：
- 团队独立性： 不同团队可以独立开发、测试和部署自己的微前端应用，减少团队之间的合作和依赖。
- 技术栈灵活性： 可以根据项目需求和团队技术偏好选择不同的技术栈，提高开发效率和质量。
- 代码复用性： 可以将通用的功能和组件抽象为独立的微前端应用，实现代码复用和模块化开发。
- 系统可扩展性： 微前端架构可以根据业务需求动态地添加、删除或替换微前端应用，实现系统的可扩展性和可维护性。
一、微前端的前世今生
前后端模块架构经历了前后端不分离-前后端分离-后端微模块-前端微前端等历程。 随着团队规模的不断增大，"巨石应用"的诞生，新技术栈的升级牵一发而动全身。业务线的增加和团队分工的划分，前端开始需要做集成和拆分。
二、微前端的理想状态及局限
- 模块级别独立使用
- 技术栈无关
- 独立开发，独立部署 后端是UI和执行过程无关的，只关心数据，所以做微服务拆分比较清晰，前端因为运行在一个浏览器环境中，加上UI也需要统一，数据需要通信，还有资源加载和冲突等等考虑因素，目前的微前端方案大部分只能支持到页面集成，对于模块级的处理仍比较困难。
三、微前端的现状和现有的解决方案
微前端很多时候是要和老旧程序打交道的，而不是新的应用程序就是设计成微前端。 目前有四种思路：
- webComponent
- Micro-APP
- Iframe（过于旧，有很多问题
- 模块联邦（过于新，对开发者素质要求高
- single-SPA（既是解决方案，也是一个框架）
- QIANKUN
Iframe
四、局限与缺点
1.DOM不共享
2.URL与内容不能做联动
3.全局上下文隔离，优点和缺点共存，优点是两个应用之间的状态不会互相影响，缺点是通信困难（比如登陆状态不能共享，子应用需要再登陆一次）
4.创建元素速度慢，浏览器上下文需要重建，资源需要重新加载
5.SEO不友好，无障碍读取困难，可用性降低
6.样式隔离
7.跨域限制
8.安全问题（使用不当容易造成XSS攻击）
9.路由会导致重新加载iframe页面，页面刷新而不是组件切换
五、single-SPA
方案：把一个子应用看成是一个单页应用的页面。每个子应用导出生命周期函数，由应用容器（父应用）调用和传值。相当于使用了子应用打包之后的产物（JS代码），它仅仅是实现了路由和应用入口，解决了上下文隔离的问题，其他微前端需要处理的问题都没有实现。
single-SPA也是基于页面集成的。
六、阿里 QianKun
阿里提供的框架，基于single-SPA的二次开发，中心思想也是容器-子应用思路，single没有考虑到子应用所需要的资源都打包到JS中过大问题，QK利用了每次打包之后的 index-html，读取之后将其放在基座应用中。遇到JS，CSS之后再读一次，单独处理。路由规则和应用入口还是基于singleSPA的，打包之后还是导出一个生命周期，在应用基座中还是跑生命周期，只不过不再读取打包后的JS了，而是读取indexhtml。 QK依旧是基于页面集成，达不到基于某个模块做集成。
QK在single基础上做了很多额外的处理工作：
1.CSS隔离
2.JS隔离
3.路由状态
4.通信方式
5.预加载
七、京东 Micro-APP
基于WebComponent的H5方案，和QK一样，MA也是读取index Html，也是基于页面集成的，其实就是把HTMl当作入口，再读取里面的内容。通过Eval执行里面的 JS，其他的模块和QK一模一样。
八、WebPack5 模块联邦 module Federation
必须基于webpack5+（技术栈相关），属于微模块级别，能做到把A应用的B模块嵌入C应用中。
基于Single系列都有一个共同的要求，都需要一个应用容器来承载子应用。但模块联邦方案不需要基座应用，它是去中心化的。
缺点：
1.技术栈相关，违背微前端的初衷和要求，比如vite项目就无法集成过来。
2.对团队成员水平有要求。现在的集成很多时候都是业务集成，如果没有基座应用去中心化，人员水平参差不齐会难以控制。
模块联邦出现的时间还太短，单独做微前端方案不够成熟。可以和QK，MA组合使用不过可以把它作为一个代码共享的工具。