Micro Frontend 实践

引言

随着大型单体前端应用（Monolith）不断膨胀，其维护成本、部署速度和技术栈升级的难度呈指数级上升。微前端（Micro Frontends）借鉴了微服务的思想，将庞大的应用拆分为多个独立开发、独立部署的子应用。

微前端的核心解决痛点

技术栈无关性

不同的团队可以根据业务需求自由选择 React、Vue、Angular 或原生 JS 来开发子应用，而无需强制全公司统一技术栈。

独立部署与交付

子应用的发布不依赖主应用和其他子应用，各团队能够独立迭代、随时上线，降低了回归测试的成本。

增量升级与重构

对于历史遗留的“屎山”项目，微前端提供了一条温和的重构路线：新功能采用新架构作为独立的子应用引入，老功能逐步迁移，避免了全量重写的巨大风险。

主流方案深度对比

传统路由分发与 iframe

• 路由分发：直接在 Nginx 层面根据路径分发到不同的独立 SPA。体验不佳，每次切换都会导致整页刷新。
• iframe：隔离性最强，但存在历史记录丢失、弹窗无法覆盖全屏、应用间通信极其困难等无法克服的体验缺陷。

single-spa 与 qiankun

• single-spa：基于路由的微前端协议，只负责子应用的生命周期调度，不提供沙箱隔离、样式隔离及预加载等工程化能力。
• qiankun：基于 single-spa 封装的开箱即用框架。它实现了：
  • JS 沙箱：基于 Proxy 拦截子应用对全局 window 的读写，防止全局变量污染。
  • 样式隔离：通过 Shadow DOM 或 CSS 作用域限制，防止样式冲突。

Module Federation (模块联邦)

Webpack 5 引入的机制。它允许一个应用在运行时动态加载另一个应用的模块，不仅能做微前端，还能实现跨应用的代码共享。它不需要像传统微前端那样定义复杂的应用生命周期，是更轻量级、更底层的一种方案。

落地实践的关键挑战

状态共享与通信

微前端应尽量保持子应用的独立性，避免过度通信。对于必要的全局状态（如用户信息、Token），可以通过自定义事件（CustomEvent）、发布订阅模式或主应用下发的全局 Store 来传递。

样式污染的彻底防范

在实践中，即便使用了 CSS Modules 或 CSS-in-JS，子应用引入的第三方 UI 库（如 Ant Design）依然可能污染全局。需要通过定制化构建流程，为第三方库的 CSS 类名自动添加统一起始命名空间。