什么是微前端：浏览器里的「微服务」

本节目标

用自己的话解释「微前端」解决了什么痛点
区分「单体前端」与「微前端」的组织差异
能说出基座应用、子应用、技术栈无关这三个关键词

微前端（Micro-Frontend）是「微服务思想」在前端的落地：把一个大应用拆成多个独立开发、独立部署、独立运行的小应用，再在浏览器里拼成一个完整页面。它和微服务的对应关系很直白——后端把一个服务拆成多个可独立部署的「服务」，前端把一个页面拆成多个可独立部署的「子应用」。

单体前端（一个团队、一套技术栈、一次发布）：
  ┌──────────────────────────────┐
  │  整个 SPA（React/Vue 混在一起） │
  │  改一处 → 全量回归 → 整体发布   │
  └──────────────────────────────┘

微前端（多个团队、可异技术栈、各自发布）：
  ┌──────────┐ ┌──────────┐ ┌──────────┐
  │ 子应用 A  │ │ 子应用 B  │ │ 子应用 C  │  各自仓库 / 各自 CI / 各自上线
  └──────────┘ └──────────┘ └──────────┘
        \            |           /
         └──── 基座应用（壳）统一挂载 ────┘

什么场景真的需要它？典型三种：

巨石应用难维护：一个跑了五年的后台，几千个组件、几十万行，新人改一行都怕炸。拆成子应用后，每个团队只管自己那一亩三分地。
技术栈要升级但不能推倒重来：老系统用 AngularJS，新需求想用 Vue3。微前端允许「老模块原样保留、新模块用新框架」，渐进式替换，而不是一次赌博式重写。
多团队并行交付：中台里订单、库存、客服是三个团队，各自有发布节奏。微前端让它们「各发各的」，互不等对方。

名词解释

微前端（Micro-Frontend）：把前端应用按业务边界拆成多个可独立开发、独立部署的子应用，在运行时由「基座」组合成一个页面的架构思想。

基座应用（Main / Shell App）：微前端的「壳」，负责菜单、布局、路由分发，并按需加载/卸载子应用。它本身通常很薄。

子应用（Sub App / Micro App）：被基座加载的业务模块，拥有自己的技术栈、仓库、构建和发布流程，对外只暴露约定的生命周期钩子。

技术栈无关（Tech-Stack Agnostic）：微前端的理想目标——子应用用什么框架都行（React / Vue / Angular / 原生），基座不关心，只要它遵守「挂载/卸载」约定。

课后练习

练习 1：微前端和「组件库」是一回事吗？

答案：不是。组件库是「同一个应用内的 UI 零件复用」；微前端是「把应用本身拆开，每个零件是一个可独立部署的完整应用」。前者解决「长得好看、别重复造按钮」，后者解决「组织怎么协作、怎么独立发布」。

练习 2：哪些情况其实不该上微前端？

答案：小团队小项目、只有一个技术栈、迭代不频繁——上微前端只会增加「基座/通信/隔离」的复杂度，得不偿失。一句话：先问「要不要独立部署」，要才考虑微前端，否则普通单体 SPA 就够了。

总结

我的判断很直接：微前端不是「更高级的写法」，而是「组织复杂度的解法」。它用「独立部署 + 运行时组合」换来团队自治和技术栈自由，代价是引入了隔离、通信、样式冲突等新麻烦。先确认你有「多团队 / 要渐进升级 / 要独立发布」的真实诉求，再上；否则单体 SPA 反而更省心。下一节我们横向对比 iframe、single-spa、qiankun、Module Federation 四种主流方案，帮你选对武器。