微前端

微前端（Micro Frontends）指的是把一个大型前端应用拆分成多个可以独立开发、独立部署、独立运行的小型前端应用，再把它们组合成一个完整系统。

它有点像后端里的微服务，只是把“拆分”的思想放到了前端。

为什么会有微前端

当一个前端系统越来越大时，往往会出现这些问题：

• 一个仓库非常庞大，启动、构建、发布越来越慢。
• 多个团队同时开发，代码冲突频繁。
• 技术栈升级困难，比如有的模块还在 Vue2，有的想上 React。
• 一个小改动也要走整个大应用的发布流程。

微前端的核心目标，就是把一个巨石前端拆开，让不同团队可以在边界清晰的前提下并行协作。

微前端的核心特征

• 子应用可独立开发。
• 子应用可独立部署。
• 子应用可按需加载。
• 不同子应用之间可以使用不同技术栈。
• 最终又能被整合成一个统一的用户入口。

常见实现方案

1. iframe 方案

最简单的微前端方式，就是把不同子系统放进不同的 iframe 中。

优点：

• 天然隔离，JS 和 CSS 基本互不影响。
• 接入简单，老系统改造成本低。

缺点：

• 通信麻烦，需要借助 postMessage。
• 路由、弹窗、样式体验割裂。
• SEO、性能、用户体验通常较差。

2. 路由分发式

主应用根据路由规则，把不同路径分发给不同子应用。

比如：

• /app1 交给 A 系统
• /app2 交给 B 系统

这种方案本质上是“页面级拆分”，适合系统之间相对独立的场景。

3. 应用组合式

主应用像加载模块一样，把多个子应用动态加载进来，并统一管理它们的生命周期。

常见框架：

• single-spa
• qiankun
• micro-app
• Module Federation

这是现在最常见的微前端落地方式。

微前端通常要解决什么问题

微前端不是简单“把页面拆开”，而是要解决一整套工程和运行时问题：

• 路由管理
• 应用加载与卸载
• JS 隔离
• 样式隔离
• 应用间通信
• 共享依赖
• 公共状态管理
• 发布与版本治理

生命周期

一个子应用在微前端框架里，通常会经历这些生命周期：

• bootstrap：初始化，只执行一次。
• mount：把子应用挂载到页面中。
• unmount：把子应用从页面中卸载掉。
• update：部分框架支持更新参数或局部刷新。

主应用负责在合适的时机触发这些生命周期。

路由怎么处理

一般有两种思路：

• 主应用控制一级路由，子应用控制自己的二级路由。
• 主应用只负责分发入口，子应用完全接管自己的内部路由。

需要注意：

• 子应用切路由不能影响其他子应用。
• 刷新页面后要能正确回到对应子应用。
• history 和 hash 模式要提前统一好。

应用间怎么通信

常见方式有：

• props 传参：主应用把数据传给子应用。
• 全局事件总线：比如发布订阅。
• postMessage：常见于 iframe 场景。
• 共享状态：比如放到全局 store 中。
• URL 参数：适合轻量场景。

原则上，子应用之间最好不要直接强耦合通信，通常通过主应用做中转会更稳。

JS 隔离

如果多个子应用同时运行在同一个页面里，就可能污染彼此的全局变量，比如都往 window 上挂东西，或者改写全局事件、定时器、原型链。

所以微前端框架通常要做 JS 隔离。

常见思路：

• iframe 隔离：最彻底，但体验差一些。
• Proxy 沙箱：对 window 做代理，让每个子应用操作自己的“假 window”。
• 快照沙箱：激活时记录全局状态，退出时恢复。

更细一点的内容可以看：微前端原理，怎么实现js隔离、样式隔离

样式隔离

不同子应用都运行在同一个 DOM 环境时，CSS 很容易互相污染。

常见做法：

• 约定命名空间，比如给类名加统一前缀。
• CSS Modules。
• Shadow DOM。
• 微前端框架在运行时对样式做作用域改写。

共享依赖

如果每个子应用都各自打包一份 React、Vue、组件库，会造成资源重复加载，包体积也会变大。

所以很多微前端方案会做共享依赖：

• 构建时共享，比如 Module Federation
• 主应用统一注入公共依赖
• CDN 外链共享基础库

但共享依赖也会带来版本兼容问题，所以要控制好依赖边界。

微前端的优点

• 支持多团队并行开发。
• 支持分模块独立部署。
• 便于渐进式重构老系统。
• 可以允许不同技术栈共存。
• 有利于把超大前端系统拆解成更清晰的业务边界。

微前端的缺点

• 架构复杂度明显上升。
• 路由、通信、鉴权、样式、监控都要额外设计。
• 首屏性能可能变差。
• 调试链路更复杂，问题定位更难。
• 如果拆分边界不合理，最后只是“分布式的混乱”。

适用场景

更适合：

• 中后台平台
• 多团队共同维护的大型系统
• 需要逐步拆分旧系统的项目
• 希望不同业务线独立发布的场景

不太适合：

• 规模很小的项目
• 团队人数不多的项目
• 页面很简单但强行上复杂架构的项目

和组件化的区别

• 组件化：拆的是页面中的 UI 单元。
• 微前端：拆的是独立可运行的应用。

组件通常不能独立部署，而微前端子应用通常可以独立部署。

和 monorepo 的区别

• monorepo 解决的是代码仓库管理方式问题。
• 微前端解决的是前端应用拆分与运行时集成问题。

两者不是替代关系，而是经常一起出现：

• 你可以用 monorepo 管理多个微前端子应用。
• 也可以不用 monorepo，但仍然做微前端。

面试版本

• 微前端就是把一个大型前端应用拆成多个可独立开发、独立部署、独立运行的子应用，再由主应用统一集成。
• 它主要解决大型前端项目团队协作、独立发布、技术栈共存和老系统渐进重构的问题。
• 微前端落地时要重点解决路由管理、生命周期、应用通信、JS 隔离、样式隔离和共享依赖。
• 常见方案有 iframe、single-spa、qiankun、micro-app、Module Federation。
• 优点是边界清晰、团队自治、可渐进重构；缺点是系统复杂度和治理成本更高。

reference