454979849 / qiankun-admin-template

主应用使用react17和react hooks，子应用模板分别使用react17和vue3.0，UI风格统一，使用的是ant design和ant design vue

什么是微前端

微前端就是与多个可以独立发布功能的团队一起构建现代化web应用程序的技术、策略和方法，将大而可怕的事物分割成更小、更易于管理的部分，然后明确它们之间的依赖关系。我们的技术选择，我们的代码库，我们的团队，以及我们的发布过程都应该能够相互独立地操作和进化，而不需要过度的协调。微前端架构是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

---

为什么不是iframe

iframe 最大的特性就是提供了浏览器原生的硬隔离方案，不论是样式隔离、js 隔离这类问题统统都能被完美解决。但他的最大问题也在于他的隔离性无法被突破，导致应用间上下文无法被共享，随之带来的开发体验、产品体验的问题。

1. url 不同步。浏览器刷新 iframe url 状态丢失、后退前进按钮无法使用。
2. UI 不同步，DOM 结构不共享。想象一下屏幕右下角 1/4 的 iframe 里来一个带遮罩层的弹框，同时我们要求这个弹框要浏览器居中显示，还要浏览器 resize 时自动居中..
3. 全局上下文完全隔离，内存变量不共享。iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果。
4. 慢。每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程。

---

微前端架构具备以下几个核心价值：

• 技术栈无关

主框架不限制接入应用的技术栈，微应用具备完全自主权

• 独立开发、独立部署

微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

• 增量升级

在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

• 独立运行时

每个微应用之间状态隔离，运行时状态不共享

微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。

---

微前端架构中一般会有个容器应用（container application）将各子应用集成起来，职责如下：

渲染公共的页面元素，比如 header、footer 解决横切关注点（cross-cutting concerns），如身份验证和导航 将各个微前端整合到一个页面上，并控制微前端的渲染区域和时机

理想的代码自然是模块清晰、依赖明确、易于扩展、便于维护的……然而，实践中出于各式各样的原因：

• 历史项目，祖传代码
• 交付压力，当时求快
• 就近就熟，当时求稳……

总存在一些不那么理想的代码：

• 技术栈落后，甚至强行混用多种技术栈
• 耦合混乱，不敢动，牵一发何止动全身
• 重构不彻底，重构-烂尾，换个姿势重构-又烂尾……
• 而要对这些代码进行彻底重构的话，最大的问题是很难有充裕的资源去大刀阔斧地一步到位，在逐步重构的同时，既要确保中间版本能够平滑过渡，同时还要持续交付新特性：

所以，为了实施渐进式重构，我们需要一种增量升级的能力，先让新旧代码和谐共存，再逐步转化旧代码，直到整个重构完成