React 微前端架构实践

困难 🔴React 生态
8 个标签
预计阅读时间：35 分钟
React微前端Module Federation架构qiankunsingle-spaWeb Components样式隔离

React 微前端架构实践

微前端（Micro Frontends）是将大型前端应用拆分为多个独立开发、独立部署、独立运行的小型应用，再在运行时把它们组合成一个完整产品的架构模式。它把后端「微服务」的思想搬到了浏览器端。

一个类比先建立直觉

把一个巨型电商网站想象成一座大型商场：

•商场本身（容器/基座应用）：负责统一的入口、导航、水电（公共服务）、楼层指引（路由）。
•每一家店铺（微应用）：商品区、订单区、会员中心、营销活动，各自有独立的装修（技术栈）、独立的营业时间（部署节奏）、独立的店员（团队）。
•商场规则（通信协议 / 隔离约定）：店铺之间不能互相串味（样式隔离），共享的空调和消防（公共依赖），店铺之间要传消息得走商场广播（通信机制）。

顾客走进商场，感觉像逛「一家店」，其实背后是几十家独立经营的店铺协同工作。这就是微前端追求的体验：用户无感知的一体化，团队高度自治的分散化。

微前端核心概念

什么是微前端：

•将大型应用按业务域拆分为多个小型应用（微应用 / 子应用）。
•每个微应用可以独立开发、独立测试、独立部署、独立发布。
•由一个「容器应用」（也叫基座 / shell / host）在运行时加载并集成这些微应用。
•对最终用户呈现为一个统一、无缝的产品。

为什么需要微前端（解决什么痛点）：

•巨石应用（Monolith）难以维护：单个仓库几十万行代码，构建一次要十几分钟，任何小改动都要全量回归。
•多团队协作冲突：几十个开发者共用一个代码库，合并冲突频繁，发布需要排队。
•技术栈被锁死：老项目用 React 16 + class 组件，想升级到 React 18 或引入 Vue 却牵一发动全身。
•遗留系统迁移困难：不能推倒重来，需要「一边跑一边换轮子」的渐进式迁移能力。
•发布耦合：一个模块的 bug 导致整个应用无法上线，发布风险高。

优势：

•团队独立开发、独立发布，加快迭代速度，降低沟通成本。
•技术栈可独立选择与演进，新老技术共存。
•故障隔离，单个微应用崩溃不会拖垮整站。
•按需加载，首屏只加载当前需要的微应用，提高性能。
•增量升级：可以逐个微应用地重构，而不是一次性大爆炸式重写。

挑战（也是本文重点要解决的问题）：

•集成复杂性：如何加载、挂载、卸载子应用。
•样式隔离：避免不同微应用的 CSS 互相污染。
•JS 隔离 / 沙箱：避免全局变量、window 属性互相覆盖。
•状态管理与通信：微应用之间如何传数据、发事件。
•路由协调：容器与子应用的路由如何配合。
•公共依赖共享：React、ReactDOM、组件库如何只加载一份。

主流实现方案原理

方案一：iframe

最古老也最简单的方案。每个微应用是一个独立页面，容器用 `