微前端架构:大型应用的拆分

一、微前端是什么:前端版的微服务

先说清楚一个常见误解:微前端不是某个具体框架,也不是什么新技术,它是一种架构风格。

后端世界里,当单体应用(Monolith)膨胀到几十万行代码、几十个团队同时改动、每次发布都要全员排队时,大家把它拆成了微服务。每个服务独立部署、独立扩缩容、独立技术选型,通过 HTTP/gRPC 通信。

前端走到同样的十字路口,往往是这样的场景:一个运营后台、一个 SaaS 控制台、或者一个电商前台,React/Vue 项目源码几十 MB,Webpack 冷启动五分钟,改一个按钮要走完整个 CI 流程,五个业务团队为了抢一个发版窗口吵架。这时候有人翻出了微服务的剧本,问:能不能把前端也拆开,让每个团队独立部署自己的那一块?

这就是微前端。ThoughtWorks 在 2016 年首次把它放进技术雷达,核心定义就一句话:把一个前端应用拆成多个可以独立开发、独立部署、独立交付的小应用,在运行时组合成一个整体对用户呈现。

关键词是独立部署。不是简单的代码分目录、组件拆分——那只是工程组织。微前端要求每个子应用有自己的构建管线、自己的发布节奏、自己的生产环境,最终在用户浏览器里拼成一个完整的页面。

听起来很美,代价我们后面讲。先看怎么实现。

二、四种主流实现方式

实现微前端的技术路径,本质上是回答一个问题:A 应用如何把 B 应用加载进来,并在同一个页面里渲染。这个问题有四种主流答案,各有取舍。

1. Module Federation(模块联邦)

Webpack 5 引入的特性,Rspack/Vite 生态也已经跟进。它让一个应用可以在运行时从另一个应用的构建产物里导入模块,就像导入本地模块一样自然。

// host 应用的 webpack 配置
new ModuleFederationPlugin({
  remotes: {
    dashboard: 'dashboard@https://cdn.x.com/remoteEntry.js',
  },
})

// host 应用里直接 import 远程组件
const Dashboard = React.lazy(() => import('dashboard/Dashboard'))

远程模块在运行时拉取,本地代码无感知。它是目前主流方案——不靠 iframe 的硬隔离,也不靠路由分发那种"硬切",运行时集成度高,开发体验最接近单仓库。

代价是:它和 Webpack/Rspack/Vite 的构建管线深度耦合,配置心智负担不轻;TS 类型共享、版本协商、双实例问题(React 被加载两次会直接报错)都需要专门处理。Vite 官方插件 vite-plugin-federation 在生产环境目前仍以 Rollup 为底,异步 chunk 的边缘 case 比 Webpack 多一些,生产前要做完整回归。

2. iframe

最古老、最朴素也最被嫌弃的方案:把子应用整个塞进 iframe 里。

优点是天然隔离:CSS、JS、全局变量、依赖版本,全部互不干扰,跨技术栈(React + Vue + 裸 HTML)都行。但它的问题和它的优点一样突出:

• 性能差:每个 iframe 都是一份独立的浏览器上下文,内存开销大,首屏慢;
• UX 难受:模态框、下拉菜单、toast 默认被 iframe 边界裁切;滚动嵌套、焦点陷阱、a11y 都要单独治;
• 通信繁琐:postMessage 是唯一通道,跨域还要处理 cookie、登录态穿透;
• 历史记录、SEO、打印、复制粘贴、键盘快捷键……每一个都得打补丁。

iframe 适合做"嵌入第三方内容"(比如一个独立的、不要它污染主页面的工具面板),不适合做产品主框架。但很多团队的微前端尝试是从 iframe 开始,因为两天就能上线。

3. Web Components(自定义元素)

子应用暴露成 <my-dashboard></my-dashboard> 这样的自定义元素,宿主把它们当普通 HTML 标签使用。Shadow DOM 提供样式隔离,框架无关(React/Vue/Svelte 都能写成 Web Component 输出)。

它的吸引力在于框架中立:宿主是 React,子应用是 Vue,完全没问题,因为它们都退化成了 DOM 元素。设计系统也常以 Web Components 形态分发,天然跨技术栈复用。

缺点是:状态、路由、SSR 都要自己造轮子;Shadow DOM 的样式隔离在某些设计系统场景下反而是负担(主题切换、全局字体、a11y 的 focus 管理都要穿透 shadow boundary);在 React 里用 Web Components 历史上有不少属性传递的坑(className 不生效等),React 19 才基本理顺。它更适合做组件级集成,而不是完整子应用集成。

4. 路由分发(Nginx/反向代理)

最简单的"假微前端":不同路径对应不同应用,由 Nginx 或网关把请求路由到不同的静态资源服务器。/dashboard 走 A 应用,/orders 走 B 应用,页面之间靠链接跳转。

它严格说不算"运行时组合",因为切换就是一次整页刷新。但很多团队把它当微前端的入门台阶,因为它几乎没有改造成本,部署最简单,隔离最彻底。

缺点也很明显:不是真正的单页面应用。跨子应用之间无法共享状态、无法平滑过渡,每次跳转用户都看得到 loading。它适合业务线之间天然隔离、用户也不会频繁跨业务切换的场景(比如不同 SaaS 模块、不同运营工具)。

一张对比表

没有"最好"的方案,只有"最合适当前约束"的方案。选型的核心问题是:你的子应用之间是"拼成一个连续体验"还是"各自独立的工具"? 前者只有 Module Federation 真正合适,后者路由分发或 iframe 就够。

三、共享问题:设计系统、依赖、状态

拆完之后,立刻冒出来的就是共享问题。一个公司有六个子应用,如果设计系统各写一份、React 各装一版、登录态各存一份,那不是微前端,是六套重复造轮子。

设计系统共享是最容易也最该先做的。一份统一的设计 token(颜色、间距、字号、圆角、动效曲线),一套基础组件库(Button、Input、Modal、Table),通过内部 npm 私有源发布,各子应用作为依赖安装。设计 token 可以用 CSS variables 在运行时注入,实现主题切换。核心原则:跨子应用 UI 一致性靠"同源的设计系统",而不是"运行时去同步样式"。

依赖共享是 Module Federation 的拿手好戏。React、ReactDOM、Lodash 这些被多个子应用共同使用的库,可以配置成 "shared",运行时只加载一份。但要注意版本协商:如果子应用 A 要 React 18.0,子应用 B 要 React 18.3, Federation 会按语义化版本协商出一个共享版本,要求所有子应用都能接受。实践中要约定一个"共享依赖版本窗口",并通过 CI 检查约束。

状态共享是最微妙的。完全共享一个 store(比如 Redux)会让子应用耦合死,失去独立性。推荐做法:跨子应用的状态走"事件 + 通信层"(自定义事件、轻量 EventBus、或 postMessage),而不是共享内存里的 store。每个子应用内部用自己的 store,跨子应用只通过契约事件通信——这和后端微服务通过事件/Kafka 通信是同一套思路。

登录态、用户信息这种全局上下文,通常由宿主应用(Shell)持有,通过 props 或 context 注入到子应用。子应用不知道怎么登录,它只消费一个 user 对象。

四、微前端的代价

到这里你应该能感觉到,微前端不是免费的午餐。它的每一项收益都对应一份代价。

复杂度爆炸。构建管线从一套变成 N 套,每个子应用要自己的 CI/CD、自己的环境变量、自己的版本号、自己的回滚机制。Module Federation 的远程入口(remoteEntry.js)如果版本漂移,宿主可能拉到一个不兼容的子应用——你们要么引入契约测试(contract testing),要么承受偶发的线上事故。部署顺序也变成问题:宿主升级和子应用升级,谁先谁后?

性能问题。即使做了依赖共享,跨子应用的代码分割也比单仓库粗放,首屏常常要拉多个 remoteEntry,加载链路更长。没有 SSF(Server-Side Fetch)协同的话,TTFB 之后还有一长串瀑布。iframe 方案的内存开销尤其夸张,开五个 tab 能把浏览器拖崩。

UI 一致性风险。设计系统虽然共享,但每个团队都有自己的"小创新":这里改个间距,那里自定义个按钮。半年不治理,六个子应用看起来像六个公司的产品。需要专门的设计系统团队(SDK Team)兜底,定期巡检。

通信成本。跨子应用通信要设计契约、版本、向后兼容,一旦子应用 A 发了一个事件,子应用 B 没监听,bug 排查链路跨仓库、跨团队,排查成本指数级上升。

团队组织成本。微前端要求团队按业务边界切分,每个子应用有明确的 owner。如果你们的组织结构本来就是按职能切(前端组、后端组、设计组),强行上微前端只会制造跨团队协调成本。康威定律在这里又一次应验:架构会反向塑造组织,组织也会反向要求架构。

五、什么时候该上,什么时候不该

说完了代价,什么时候微前端真的值得?我给三条硬指标,满足至少两条再认真考虑:

1. 超大团队、多业务线。前端团队规模 50 人以上,或者三个以上独立业务团队需要并行迭代,且业务边界清晰。一个 10 人小组绝对用不着微前端。
2. 独立部署的强需求。不同业务线有完全不同的发布节奏、合规要求、灰度策略,挤在单仓库里互相阻塞。比如金融业务要严格审计每次发布,运营业务要每天多次小步快跑,放一起就是互相拖累。
3. 技术栈异构。某些子业务因为历史包袱或特殊需求必须用不同技术栈(Vue + React 共存,或老 Angular + 新 React 共存),无法统一迁移。

反过来,这几种情况不要上微前端:

• 中小团队(几个到十几个前端):单仓库 + Monorepo 完全够用,微前端带来的复杂度远超收益;
• 单一技术栈、单一业务线:没有团队协作瓶颈,没有独立部署诉求,微前端是负收益;
• 为了"看起来先进":技术选型被简历驱动,不是被业务驱动;
• 为了"解决构建慢":这是工程问题,换 Vite/Turbopack、做构建缓存、拆包都能解决,不用上架构层面的微前端;
• "先拆了以后好扩展":过早优化,等你真需要拆的时候,业务形态早就变了。

六、多数时候,Monorepo + 组件库就够了

我见过太多团队,把微前端当"解决前端工程组织问题的银弹",半年后发现自己在维护一个比原单体复杂三倍的怪物,然后默默回滚。大多数场景下,Monorepo + 设计系统 + 组件库,是远比微前端更优的解。

Monorepo(pnpm workspace、Nx、Turborepo)给你:

• 代码共享天然简单:设计系统、工具函数、类型定义,直接 import 同仓库的 package;
• 原子化跨包改动:重构一个被十几个应用用的组件,一次 PR 全部更新到位,微前端里这种事要协调 N 个仓库发版;
• 统一构建工具链:一套 CI、一套 lint、一套 tsconfig,新人上手快;
• 增量构建:Turborepo/Nx 的构建缓存让 CI 只跑受影响的部分,比微前端的"每个子应用一套 CI"更省。

Monorepo 解决的是代码组织问题,微前端解决的是部署与组织边界问题。前者是后者的子集——只有当代码组织已经无法满足"独立部署""团队边界对齐"的诉求时,才有理由升级到微前端。

我的建议是:从 Monorepo + 内部组件库 + 设计系统起步,把工程治理做到位。等到某一天你发现某个 package 的发布节奏必须独立、某个团队必须用不同的技术栈、某个业务必须独立扩缩容——那时再把这个 package 拆成独立的子应用,迁到微前端。微前端是演化的结果,不是起点。

组件库和设计系统做得好,即使将来真的要拆,迁移也相对平滑——因为子应用的边界早就内化在 package 结构里了。反过来,如果一开始就上微前端,后期想合并回单仓库几乎是噩梦。

小结

• 微前端 = 前端版微服务:核心是独立开发、独立部署、运行时组合,不是具体的框架或技术。
• 四种实现各有定位:Module Federation 是运行时集成的主流,iframe 隔离强但体验差,Web Components 适合跨技术栈组件,路由分发最简单但不是 SPA。
• 共享设计系统是底线:设计 token + 组件库走私有 npm,跨子应用靠"同源"而不是"同步"。
• 代价是真金白银:构建部署复杂度、性能开销、UI 治理成本、跨团队协作成本,每一项都要算清。
• 门槛比想象的高:50 人以上前端、多业务线独立部署、技术栈异构——满足至少两条才认真考虑。

最后一句金句送给在做选型的你:Monorepo + 组件库是 80% 团队的最优解,微前端是最后手段,不是默认选项。当你犹豫要不要上微前端时,答案几乎一定是"不要"。