一、什么是微前端？
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently . -- Micro Frontends
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端（Micro-frontend，简称 MFE）是一种类似于微服务的架构，是一种由独立交付的多个前端应用组成整体的架构风格，它将前端应用分解成一些更小、更简单的能够独立开发、测试、部署的应用，而在用户看来仍然是内聚的单个产品。 -- modernjs
微前端，同微服务的核心思想是相通的「分而治之」------ 将一个庞大的前端应用拆解为多个独立、自治、可组合的前端子应用。每个子应用可以使用不同的技术栈（如Vue、React、Angular），由独立的团队负责开发、测试、部署和维护；同时，存在一个"主应用"，负责子应用的注册、路由分发、资源加载和整合，最终向用户呈现一个统一的产品体验。
- 更小、更具凝聚力且更易于维护的代码库
- 更具可扩展性的组织，拥有解耦、自主的团队
- 能够以比以往更加渐进的方式升级、更新甚至重构前端的部分代码。
二、为什么需要微前端？
主要是微前端可以解决单体应用的哪些弊端
1. 解决团队协作阻塞问题
在大型前端项目（特别是SaaS化平台）中，往往会有多个团队共同开发。传统单体应用中，所有团队都在同一个代码仓库中开发，很容易出现代码冲突、分支管理混乱等问题。
微前端通过拆分应用，让每个团队负责一个独立的子应用。++团队之间通过约定好协作方式，无需关心对方的内部实现，有效避免了代码冲突和迭代节奏不一致的问题，提升了团队协作效率。++
2. 打破技术栈锁定
传统单体应用一旦确定了技术栈，后续很难更换。比如早期用jQuery开发的项目，随着业务发展需要使用Vue、React等现代框架，但重构整个项目的成本极高，风险也很大。
++微前端支持多技术栈共存，新的子应用可以使用最新的技术栈开发，而遗留系统可以作为子应用继续运行，无需一次性重构。++ 同时，还可以根据不同子应用的业务特点选择最合适的技术栈。
3. 支持增量升级与迭代
对于大型遗留系统，微前端提供了增量升级的方案：可以将遗留系统拆分为多个子应用，然后逐步用现代技术栈重写这些子应用，++每次只升级一个子应用，不影响整个系统的正常运行。++
此外，每个子应用都可以独立迭代和部署，无需等待整个系统的版本周期。
4. 提升系统稳定性与可维护性
单体应用的代码量庞大，逻辑复杂，一旦某个模块出现问题，很可能影响整个系统的运行。微前端将系统拆分为多个独立的子应用，++子应用之间相互隔离，一个子应用的故障不会扩散到其他子应用，提升了整个系统的稳定性++。
同时，团队只需关注自己负责的子应用，无需熟悉整个系统的代码，降低了新人上手的难度。
三、哪些项目适合用微前端？
微前端的核心优势
✔️ 技术栈无关： 主框架不限制接入应用的技术栈，微应用具备完全自主权
✔️ 独立开发、独立部署： 微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
✔️ 增量升级： 渐进式重构的手段和策略（对于存量系统做技术栈升级或重构尤为显著）
✔️ 独立运行时： 每个微应用之间状态隔离，运行时状态不共享
⚠️ 微前端不是"银弹"，如果你的项目是小型应用，功能简单，团队规模小，使用单体应用反而更高效。下述列举一些经典场景：
| 场景 | 解决痛点 |
|---|---|
| 大型中后台系统 | 包含多个业务模块（OPS/ERP/BI），不同业务线需独立迭代 |
| 多团队协作项目 | 团队协作中的冲突（节奏、技术栈等）问题 |
| 遗留系统重构 | 全量重构风险过高，逐步替换、增量升级 |
四、微前端核心能力
支持上述特性（优势），微前端架构需要具备哪些能力
子应用的加载和卸载能力
🎯 按需加载、无缝切换、资源回收
❗️ 关键问题：
- 如何动态加载子应用的 HTML、JS、CSS
- 切换时是否造成内存泄漏（如事件监听、定时器未清理）
- 首屏性能 vs. 按需加载的平衡
📌 典型实现：
- 静态资源加载：通过
fetch + eval / import()加载 JS，动态插入<link>/<style>。 - 生命周期钩子：提供 bootstrap（初始化）、mount（挂载）、unmount（卸载）等标准接口。
- 沙箱辅助：在 unmount 时自动清理副作用（如 qiankun 的 snapshot 沙箱）。
子应用独立运行的能力
🎯 防止"一个子应用崩溃，全站瘫痪"
❗️ 三大污染源：
- JS 全局污染：
window.xxx = ...覆盖主应用或其他子应用变量 - CSS 样式冲突：全局样式（如
.btn { color: red }）影响其他模块 - 浏览器 API 滥用：
addEventListener('click', ...)未解绑，造成事件堆积
📌 隔离方案：
- JS 隔离：
- 快照沙箱（Snapshot Sandbox）：记录 window 快照，卸载时还原（适用于单实例）
- Proxy 沙箱：用
new Proxy(window)拦截属性读写（支持多实例，如 qiankun v2+）
- CSS 隔离：
- CSS Modules / Scoped CSS（编译时）
- CSS-in-JS（运行时作用域）
- Shadow DOM（强隔离，但兼容性 & 通信成本高）
- 命名空间前缀（如 .app1 .btn，简单但易遗漏）
子应用路由状态保持能力
🎯 用户感知不到"这是多个应用"
❗️关键挑战：
- 主应用与子应用路由如何协同？（如 /app1/user → /app2/order）
- 刷新页面后，如何精准激活对应子应用并恢复其内部路由？
📌 实现策略：
- 主控路由（Router-based）：
- 主应用监听 hash / history 变化，匹配子应用注册的路由前缀（如
/app1/**）。 - 触发对应子应用 mount，并传递 pathname。
- 主应用监听 hash / history 变化，匹配子应用注册的路由前缀（如
- 子应用感知路由：
- 子应用内部使用自己的 Router（如 React Router），但不监听全局 popstate，而是由主应用通过 props 传入当前路径。
- 状态持久化：结合 sessionStorage 或状态管理库（如 Redux）保存子应用 UI 状态。
应用间通信的能力
🎯 安全、高效、解耦地传递数据与事件
❗️ 常见场景：
- 主应用传递用户信息给所有子应用
- 子应用 A 触发"全局通知"，子应用 B 需响应
- 子应用间共享状态（如购物车数量）
📌 通信模式：
| 模式 | 方案 | 适用场景 |
|---|---|---|
| 全局状态总线 | 自定义 EventEmitter / PubSub | 简单事件通知（如 qiankun 的 initGlobalState） |
| 依赖注入 | 主应用注入 props 到子应用 | 初始化数据（如用户、权限） |
| 中心化状态 | 共享 Redux / Zustand 实例 | 复杂状态共享（需谨慎隔离） |
| URL 传参 | 通过路由参数或 query 传递 | 跨应用跳转时传递上下文 |
微前端并非要取代单体应用，而是为复杂度超标的前端系统提供一种进化路径（架构风格）。