什么是微前端
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端架构具备以下几个核心价值：
- 技术栈无关 主框架不限制接入应用的技术栈，子应用可自主选择技术栈，具备完全自主权
- 独立开发/部署 各个团队之间仓库独立，单独部署，互不依赖
- 增量升级 当一个应用庞大之后，技术升级或重构相当麻烦，而微应用具备渐进式升级的特性
- 独立运行时 微应用之间运行时互不依赖，有独立的状态管理
- 提升效率 应用越庞大，越难以维护，协作效率越低下。微应用可以很好拆分，提升效率
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
将原本把所有功能集中于一个项目中的方式转变为把功能按业务划分成一个主项目和多个子项目，每个子项目负责自身功能，同时具备和其它子项目和主项目进行通信的能力，达到更细化更易于管理的目的。
目前可用的微前端方案
微前端的方案目前有以下几种类型：
基于 iframe 完全隔离的方案
作为前端开发，我们对 iframe 已经非常熟悉了，在一个应用中可以独立运行另一个应用。它具有显著的优点：
- 非常简单，无需任何改造
- 完美隔离，JS、CSS 都是独立的运行环境
- 不限制使用，页面上可以放多个
iframe来组合业务
当然，缺点也非常突出：
- 无法保持路由状态，刷新后路由状态就丢失
- 完全的隔离导致与子应用的交互变得极其困难，只能采用
postMessage方式。 iframe中的弹窗无法突破其本身- 整个应用全量资源加载，加载太慢
这些显著的缺点也催生了其他方案的产生。
基于 single-spa 路由劫持方案
single-spa 是社区公认的主流方案，可以基于它做二次开发。通过劫持路由的方式来做子应用之间的切换，但接入方式需要融合自身的路由，有一定的局限性。
京东 micro-app 方案
京东 micro-app 并没有沿袭 single-spa 的思路，而是借鉴了 WebComponent 的思想，通过 CustomElement 结合自定义的 ShadowDom，将微前端封装成一个类 webComponents 组件，从而实现微前端的组件化渲染。
阿里 qiankun
qiankun 对 single-spa 做了一层封装。主要解决了 single-spa 的一些痛点和不足。通过 import-html-entry 包解析 HTML 获取资源路径，然后对资源进行解析、加载。
qiankun 可以用于任意 js 框架，微应用接入像嵌入一个 iframe 系统一样简单。qiankun@2.0 将跳出 route-based 的微前端场景。
阿里 qiankun
qiankun采用运行时集成主、子应用，HTML entry作为子应用入口的中心路由基座式微前端方案。
基于single-spa实现，主、子应用都可以做到技术栈无关，方便接入子应用；完备的应用生命周期管理，子应用只需要暴露生命周期钩子即可实现应用接入。
qiankun 的核心设计理念
🥄 简单
由于主应用微应用都能做到技术栈无关，
qiankun对于用户而言只是一个类似jQuery的库，你需要调用几个qiankun的 API 即可完成应用的微前端改造。同时由于qiankun的 HTMLentry及沙箱的设计，使得微应用的接入像使用iframe一样简单。🍡 解耦/技术栈无关
微前端的核心目标是将巨石应用拆解成若干可以自治的松耦合微应用，而
qiankun的诸多设计均是秉持这一原则，如 HTMLentry、沙箱、应用间通信等。这样才能确保微应用真正具备 独立开发、独立运行 的能力。
特性
- 📦 基于
single-spa封装，提供了更加开箱即用的API。 - 📱 技术栈无关，任意技术栈的应用均可 使用/接入，不论是
React/Vue/Angular/JQuery还是其他等框架。 - 💪 HTML Entry 接入方式，让你接入微应用像使用
iframe一样简单。 - 🛡 样式隔离，确保微应用之间样式互相不干扰。
- 🧳 JS 沙箱，确保微应用之间 全局变量/事件 不冲突。
- ⚡️ 资源预加载，在浏览器空闲时间预加载未打开的微应用资源，加速微应用打开速度。
- 🔌 umi 插件，提供了
@umijs/plugin-qiankun供 umi 应用一键切换成微前端架构系统。
缺点
- 上线部署文档较少
qiankun只能解决子项目之间的样式相互污染，不能解决子项目的样式污染主项目的样式qiankun是目前是社区主流微前端方案。它虽然很完善、流行，但最大的问题就是不支持Vite。
安装流程
见官网 快速上手
