1.什么是微前端？
核心：将大型系统拆分成子系统
微前端是一种架构风格，旨在将大型前端应用程序拆分为更小、更可管理的部分。它通过将前端应用程序划分为多个独立的子应用，每个子应用都有自己的代码库和独立的开发团队来实现。这些子应用可以独立部署、独立运行，并且可以在同一个页面上协同工作。
微前端的核心思想是将前端应用程序拆分为多个独立的功能模块，每个模块都可以独立开发、测试和部署。这样可以提高开发效率，降低代码耦合度，并且可以让不同团队独立开发不同的模块，从而提高团队的协作效率。
在微前端架构中，每个子应用都可以使用不同的技术栈和框架，因此可以根据具体需求选择最适合的技术栈。同时，微前端还提供了一些通信机制，使得不同子应用之间可以进行跨域通信和共享数据。
总之，微前端是一种将前端应用程序拆分为多个独立子应用的架构风格，可以提高开发效率、降低代码耦合度，并且可以让不同团队独立开发不同的模块，从而提高团队的协作效率。
2.为什么会出现微前端？
微前端的假设是，所有大型系统都逃不过熵增定律
这个假设指的是，所有大型系统都将从有序变为无序，他们背后的代码库的归宿都将是难以维护。
如果不是，那一定是因为这个系统使用的技术栈更新的不够快，参与系统开发的工程师不够多，产品迭代的时间不够长。
假设这样两个场景
你新入职一家公司，老板扔给你一个 5 年陈的项目，需要你在这个项目上持续迭代加功能。
你们有一个新项目，老板看惯了前端的风起云涌技术更迭，只给了架构上的一个要求："如何确保这套技术方案在 3~5 年内还保有生命力，不会在 3、5 年后变成又一个过时项目？
这两个场景对于开发人员可谓司空见惯，就前端而言，几年时间经历了从切图仔→ 原生开发→ Jquery→Vue 2→Vue 3如沧海桑田一般的技术变迁。很多时候前端程序猿苦老项目久已，只恨新技术无用武之地。微前端解决的主要问题是 “与技术无关”，在将一个大系统拆分成可独立部署与测试的小系统的时候。即解决了系统因为持续迭代带来的 “熵增” ，也可让系统减少成为 “某山”。
3.微前端的利与弊?
主要优点：
解耦： 微前端架构可以将大型项目分解为多个可以独立开发、测试和部署的小型应用。这种解耦可以提高开发效率，减少团队间的协调成本。
技术栈无关： 不同的微前端应用可以使用不同的技术栈，这为使用新技术、升级旧技术提供了可能。
并行开发： 因为微前端应用是独立的，所以多个团队可以并行开发不同的应用，无需担心相互影响。
独立部署： 每个微前端应用可以独立部署，这意味着可以更快地推出新功能，同时降低了部署失败的风险
主要挑战：
性能问题： 基于JS沙箱，存在大量with语句和沙箱代理，将会存在性能问题。
一致性： 保持不同的微前端应用在用户体验、设计和行为上的一致性可能会比较困难。
状态共享： 在微前端应用之间共享状态可能会比较复杂，需要使用特殊的工具或模式。
复杂性： 尽管微前端可以解决大型项目的复杂性问题，但是它自身也带来了一些复杂性，比如需要管理和协调多个独立的应用。
安全性： 微前端架构可能会增加跨域，eval函数等安全问题。
4.我们需要使用微前端?
基于以上观点，我们可以概括出，存在以下场景时，你可能就不需要微前端：
1. 你的团队 具备系统内所有架构组件的话语权。简单来说就是，系统里的所有组件都是由一个小的团队开发的。
2. 你的团队 有足够动力去治理、改造这个系统中的所有组件。直接改造存量系统的收益大于新老系统混杂带来的问题。
3. 系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的。系统本身就是一个最小单元的，拆分的成本高于治理的成本。
4. 极高的产品体验要求，对任何产品交互上的不一致零容忍。不允许交互上不一致的情况出现，这基本上从产品上否决了渐进式升级的技术策略。
满足以下几点，你才确实可能需要微前端
1. 旧的系统不能下，新的需求还在来，没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。
2. 你的系统需要有一套支持动态插拔的机制。这个机制可以是一套精心设计的插件体系，可以组合部署不同的系统来进行按需定制。比如：一个客户需要OA系统的人事模块与财务模块，另一个客户只需要人事模块，那么我们就可以按需部署。避免部署整个系统，然后来鉴权实现。
3.系统中的部件具备足够清晰的服务边界。通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中。
还是那个老生常谈的理念，没有完美的框架，架构本身就是各种“权衡利弊”。
5.目前主流微前端框架对比
| qiankun(阿里) | micro-app(京东) | 无界（腾讯） | |
|---|---|---|---|
| start | 15k | 4.8k | 3.3k |
| issue | 1900 | 780 | 540 |
| 首个版本 | v1.1.4 (2019-08-01) | v0.1.0 (2021-07-09) | 1.0.0-rc.1 (2022-07-05) |
| 接入成本 | 高 | 低 | 低 |
| 实现方案 | 监听 url change 事件 | webComponent + iframe | webComponent + iframe |
| 优势 | 1.相对成熟，社区比较活跃 2.经过大量项目验证（同时问题也不少） | 1.支持Vite 2.接入成本低 | 1.支持Vite 2.接入成本低 |
| 劣势 | 1.适配成本比较高，工程化、生命周期、静态资源路径、路由等都要做一系列的适配工作2.css 沙箱采用严格隔离会有各种问题，js 沙箱在某些场景下执行性能下降严重；3.无法同时激活多个子应用，也不支持子应用保活；4.无法支持 vite 等 esmodule 脚本运行； | 1.浏览器兼容性略差，对于不支持proxy 的浏览器没有做降级处理 | 1.隔离js使用一个空的iframe进行隔离2.子应用axios需要自行适配 |
| 更新速度 | 目前是2.x版本，2023年共发布22个版本。 | 目前是1.x版本，2023年共发布11个版本。 | 目前是1.x版本，2023年共发布15个版本 |
| 兼容性 | 2.x版本不支持vite(因为原理冲突) 3.0版本支持，但目前处于内部测试版本 | 需要浏览器支持CustomElements和Proxy两api。不支持Proxy的浏览器无法运行。即主流浏览器都支持。支持方案查询caniuse.com/?search=Pro… | 需要浏览器支持CustomElements和Proxy两api。对Proxy做了兼容处理。 |
7.相关文档
Qiankun 技术圆桌链接
一个好的技术选型文章
Qiankun(阿里)
Github：github.com/umijs/qiank…
Micro-App(京东)
官网：micro-zoe.github.io/micro-app/d…
Github：github.com/micro-zoe/m…
无界(腾讯)
官网：wujie-micro.github.io/doc/guide/
Github：github.com/Tencent/wuj…
