钉子的生活日记
文章目录

微前端架构总览与选型学习笔记

适合目标：系统建立微前端的整体知识体系，完成从概念理解、方案选型、落地设计到面试表达的一整套知识闭环。
学习定位：这一份偏“总览 + 选型 + 架构”，适合作为整个微前端专题的入口文档。
学习原则：先搞清楚为什么需要微前端，再理解不同方案的边界和取舍，最后再进入具体框架。

目录

  1. 微前端到底是什么
  2. 为什么会出现微前端
  3. 微前端适用与不适用场景
  4. 微前端核心能力模型
  5. 主流方案全景图
  6. MicroApp、无界、Qiankun、Module Federation / EMP 对比
  7. Vue 和 React 现在怎么选
  8. 一个可落地的企业级微前端架构
  9. 微前端落地路线图
  10. 高频面试题
  11. 一页总结

1. 微前端到底是什么

微前端可以理解成：

把一个大型前端应用，拆成多个可以独立开发、独立部署、按需集成的前端子应用。

它借鉴了微服务思想，但不是简单把“后端微服务”搬到前端，而是在前端层面解决这些问题：

  1. 大型系统多人并行开发时的协作效率
  2. 多个历史技术栈共存时的渐进迁移
  3. 多团队独立发布时的版本耦合
  4. 超大前端工程的复杂度失控

要记住一句话：

微前端的目标不是把系统拆碎，而是把团队协作边界和应用运行边界治理清楚。

2. 为什么会出现微前端

2.1 单体前端项目在变大后常见的问题

  1. 一个仓库太大，构建慢、测试慢、发布慢
  2. 多团队改同一个项目，冲突频繁
  3. 技术栈升级困难，React、Vue、老项目互相拖累
  4. 局部业务独立性高，却必须绑定整体发布
  5. 全局依赖和样式污染难治理

2.2 微前端解决的是哪些“组织问题”

很多时候，微前端不只是技术选型，而是组织架构问题的技术映射：

  1. 团队是否按业务线分工
  2. 子系统是否需要独立迭代
  3. 历史系统是否必须渐进迁移
  4. 是否存在多个技术栈并存
  5. 是否需要平台型主应用承载多个业务域

2.3 微前端不是银弹

引入微前端以后，也会新增成本：

  1. 接入复杂度更高
  2. 运行时通信更复杂
  3. 调试链路变长
  4. 性能治理成本上升
  5. 基础设施要求更高

所以不是所有项目都值得上微前端。

3. 微前端适用与不适用场景

3.1 适用场景

  1. 中后台平台型系统
  2. 多业务线、多团队协作系统
  3. 老系统迁移到新框架的过渡期
  4. 需要独立部署、灰度发布的子业务
  5. 一个壳应用下挂多个业务子系统

3.2 不适用场景

  1. 小型官网、活动页、单业务后台
  2. 团队规模小，只有 1 到 3 个前端
  3. 没有独立发布需求
  4. 所有页面都强依赖同一份全局状态
  5. 对首屏性能极端敏感但基础设施不足

3.3 一个简单判断标准

如果你的项目满足下面至少 3 条，再认真考虑微前端：

  1. 子业务边界清晰
  2. 需要独立部署
  3. 需要多团队并行
  4. 历史技术栈不好统一
  5. 平台型主应用强于单页型应用

4. 微前端核心能力模型

一个成熟的微前端方案，通常要覆盖下面几个能力：

4.1 应用加载

  1. 路由匹配加载
  2. 资源预加载
  3. 按需挂载和卸载
  4. 同步或异步注册

4.2 隔离能力

  1. JS 运行隔离
  2. CSS 样式隔离
  3. DOM 容器隔离
  4. 全局变量污染控制

4.3 通信能力

  1. 主子应用通信
  2. 子子应用间接通信
  3. 全局事件总线
  4. 状态共享或数据订阅

4.4 生命周期管理

  1. bootstrap
  2. mount
  3. unmount
  4. update

4.5 工程治理能力

  1. 独立开发调试
  2. 独立构建发布
  3. 公共依赖复用
  4. 监控、日志、埋点统一
  5. 权限、路由、菜单统一

5. 主流方案全景图

从实现思路看，微前端方案大致可以分为 4 类：

5.1 路由分发式

主应用根据路由切换不同子系统，典型是早期 iframe 或 portal 形式。

优点：

  1. 简单
  2. 独立性强

缺点：

  1. 体验割裂
  2. 通信与样式整合差

5.2 基于 single-spa 生态的运行时集成

典型代表是 Qiankun。
核心思路是：主应用作为调度中心，按路由激活子应用，并在运行时做沙箱、样式隔离、生命周期托管。

5.3 基于 iframe 改良的方案

典型代表是 MicroApp、无界。
这类方案通常强调：

  1. 更低的接入成本
  2. 更好的多框架兼容
  3. 比传统 iframe 更自然的通信和路由体验

5.4 基于模块共享的构建时/运行时混合方案

典型代表是 Module Federation、EMP。
核心不是“应用托管”，而是“模块级共享与远程加载”。

适合：

  1. React/Vue 组件级拆分
  2. 多仓库模块复用
  3. 设计系统、组件平台、壳应用拆分

6. MicroApp、无界、Qiankun、Module Federation / EMP 对比

6.1 对比总表

方案 核心机制 接入难度 隔离能力 适合场景 优势 风险
MicroApp 类 WebComponent + iframe 沙箱思路 + 数据通信封装 低 较强 中后台、多技术栈融合 接入简单、心智负担低 深度定制和生态广度一般
无界 iframe 沙箱 + 路由同步 + WebComponent 容器 低到中 很强 老系统兼容、复杂中后台 稳定、兼容性好、隔离强 首屏和调试链路需治理
Qiankun single-spa + HTML Entry + JS 沙箱 + 样式隔离 中 中到强 平台型主应用、路由分发场景 社区成熟、概念体系完整 对资源加载、生命周期、路由耦合更敏感
Module Federation Webpack 5 原生远程模块共享 中到高 偏工程层 组件级拆分、同构建体系项目 共享依赖强、性能好、模块边界清晰 对工程体系要求高
EMP Federation 工程体系增强 中到高 偏工程层 多应用模块联邦、工程平台化 强调工程化和联邦能力 学习门槛比运行时方案更高

6.2 如何理解它们的差异

可以把它们分成两大阵营：

阵营 1：应用托管型

  1. MicroApp
  2. 无界
  3. Qiankun

重点是：

怎么把一个完整子应用安全地挂进主应用。

阵营 2：模块联邦型

  1. Module Federation
  2. EMP

重点是：

怎么把远程模块像本地模块一样按需消费。

6.3 一个直观选择建议

如果你更关注：

  1. 快速接入多个完整子系统
  2. 技术栈兼容
  3. 独立部署

优先看：MicroApp / 无界 / Qiankun

如果你更关注：

  1. 多应用共享组件
  2. 远程模块加载
  3. 同一工程体系下的高性能拆分

优先看：Module Federation / EMP

7. Vue 和 React 现在怎么选

这一节回答用户最关心的问题：

如果现在要做微前端，Vue 和 React 体系应该优先选哪个方案？

7.1 Vue 技术栈推荐

推荐优先级

  1. Vue + MicroApp
  2. Vue + 无界
  3. Vue + Qiankun
  4. Vue + Module Federation

推荐理由

对于 Vue 中后台场景，很多团队更看重：

  1. 接入速度
  2. 老项目兼容
  3. 子应用改造成本
  4. 路由和样式隔离的稳定性

这时 MicroApp 和无界通常更顺手。

Vue 场景下如何选

  1. 如果你有多个 Vue2/Vue3 子系统，需要快速接入，优先 MicroApp
  2. 如果你系统复杂、历史包袱重、隔离要求高，优先 无界
  3. 如果团队已经熟悉 single-spa 思维，且主应用做统一路由编排，选 Qiankun
  4. 如果你更强调模块共享、组件平台化，而不是整应用托管，选 Module Federation

7.2 React 技术栈推荐

推荐优先级

  1. React + Module Federation
  2. React + EMP
  3. React + Qiankun
  4. React + 无界 / MicroApp

推荐理由

React 生态和 Webpack/Vite 工程能力结合更紧，组件化和模块级拆分天然适合 Federation 思路。
如果你的目标是：

  1. 多应用共享组件
  2. 设计系统复用
  3. Shell + Remote 形态
  4. 更细粒度前端拆分

那么 Module Federation / EMP 往往更合适。

7.3 一句话结论

  1. Vue 项目优先考虑 MicroApp 或 无界
  2. React 项目优先考虑 Module Federation 或 EMP
  3. Qiankun 适合作为通用型主应用托管方案，但不一定是每个新项目的第一优先级

7.4 什么时候不要死盯框架

很多团队一开始就纠结“Vue 用哪个，React 用哪个”，但更重要的是这 4 个问题：

  1. 你是“整应用拆分”还是“模块拆分”
  2. 你是“多技术栈兼容”还是“统一工程体系”
  3. 你更怕“接入成本”还是更怕“运行时复杂度”
  4. 你是否需要“独立部署 + 独立调试 + 共享依赖”

8. 一个可落地的企业级微前端架构

8.1 推荐分层

  1. 基础设施层
  2. 主应用壳层
  3. 子应用业务层
  4. 共享能力层
  5. 监控治理层

8.2 每层职责

基础设施层

  1. CDN
  2. 网关
  3. CI/CD
  4. 统一鉴权
  5. 域名和静态资源策略

主应用壳层

  1. 菜单和布局
  2. 路由编排
  3. 用户信息
  4. 权限分发
  5. 应用注册中心

子应用业务层

  1. 独立开发
  2. 独立测试
  3. 独立部署
  4. 业务自治

共享能力层

  1. 设计系统
  2. 埋点 SDK
  3. 请求封装
  4. 登录态管理
  5. 国际化能力

监控治理层

  1. 性能监控
  2. 错误监控
  3. 日志链路
  4. 发布灰度
  5. 应用健康度看板

8.3 通信建议

不要让子应用随便互相直接调用。推荐：

  1. 主应用做通信中枢
  2. 共享状态只放必要的少量信息
  3. 业务数据尽量各自自治
  4. 复杂协作优先走接口而不是全局内存

8.4 样式建议

  1. 每个子应用必须有独立样式命名空间
  2. 通用组件库要明确主题变量边界
  3. 尽量避免全局 reset 互相覆盖
  4. 若方案支持 Shadow DOM，可按场景使用

8.5 路由建议

  1. 主应用只管一级路由
  2. 子应用内部自管二级及以下路由
  3. 避免主子路由规则重叠
  4. hash 和 history 模式要提前统一

9. 微前端落地路线图

9.1 第一阶段：先拆边界，不急着选框架

输出物：

  1. 业务域划分图
  2. 主应用职责清单
  3. 子应用边界定义
  4. 通信矩阵
  5. 发布流程图

9.2 第二阶段：PoC 验证

至少验证这些点：

  1. 本地联调是否顺畅
  2. 独立部署是否可行
  3. 登录态是否可共享
  4. 样式是否污染
  5. 路由切换是否稳定
  6. 错误是否可观测

9.3 第三阶段：制定接入规范

  1. 子应用目录规范
  2. 生命周期暴露规范
  3. 路由前缀规范
  4. 通信 API 规范
  5. 静态资源 publicPath 规范
  6. 埋点和监控接入规范

9.4 第四阶段：逐步迁移

  1. 新业务优先按微前端规范开发
  2. 老业务分模块迁移
  3. 不要一次性全量改造
  4. 先解决高收益、高独立性的子系统

10. 高频面试题

10.1 什么是微前端

答题模板：

微前端是把大型前端应用拆分为多个可独立开发、独立部署、按需集成的子应用方案。它借鉴了微服务思想，但重点解决的是前端多团队协作、技术栈共存、独立发布和复杂度治理问题。

10.2 微前端解决了什么问题

  1. 多团队协作冲突
  2. 老系统渐进迁移
  3. 独立发布
  4. 平台型系统扩展
  5. 超大前端工程治理

10.3 微前端的核心难点是什么

  1. 路由治理
  2. 样式隔离
  3. JS 沙箱
  4. 应用通信
  5. 公共依赖共享
  6. 性能与稳定性

10.4 Qiankun、无界、MicroApp 的核心区别是什么

可以这样答：

Qiankun 更偏 single-spa 运行时托管思路，体系成熟；
无界和 MicroApp 更强调 iframe 沙箱增强、兼容性和低改造成本；
如果团队更关注整应用接入的平滑性，无界和 MicroApp 往往更友好。

10.5 Module Federation 和传统微前端有什么不同

重点回答：

  1. 它不是主要解决整应用托管
  2. 它更强调远程模块共享
  3. 它更适合同构建体系、多应用模块复用
  4. 它更偏工程化层面的拆分

10.6 微前端一定要做沙箱吗

不一定，但规模一大基本都需要。
因为没有沙箱，子应用很容易污染：

  1. window
  2. 定时器
  3. 事件监听
  4. 全局样式
  5. 路由状态

10.7 微前端的性能风险有哪些

  1. 首屏加载多个子应用资源
  2. 重复依赖下载
  3. 切换时 mount/unmount 成本
  4. 沙箱开销
  5. 预加载策略不合理

10.8 面试时怎样讲选型

推荐答法：

不要上来背框架名，先讲业务背景，再讲约束，再讲为什么选。
比如：

  1. 多技术栈并存
  2. 子系统独立发布
  3. 老系统改造成本高
  4. 团队希望低接入成本

因此选择无界或 MicroApp。
如果是 React 组件平台与远程模块复用，则选择 Module Federation。

11. 一页总结

11.1 微前端的本质

不是为了拆而拆，而是为了把团队边界、业务边界、发布边界和运行边界治理清楚。

11.2 选型口诀

  1. 整应用接入看 MicroApp、无界、Qiankun
  2. 模块共享优先看 Module Federation、EMP
  3. Vue 体系优先 MicroApp / 无界
  4. React 体系优先 Module Federation / EMP
  5. 先定边界，再定框架，不要反过来

11.3 学习顺序建议

  1. 先学微前端概念和痛点
  2. 再看 4 大方案横向对比
  3. 再精读你团队最可能落地的那一条线
  4. 最后整理一套自己的架构表达和面试答案