微前端的实现方式

左杰

微前端实现方式

微前端并没有唯一标准实现方式，主流的实践方案包括以下几类：

每个子应用运行在 iframe 中，实现物理隔离。

优点：强隔离，互不干扰
缺点：性能差、通信复杂、用户体验差（刷新、跳转不连贯）

主应用管理路由，访问某路由时动态加载对应子应用资源（JS/CSS）。
子应用可独立打包部署，使用如 SystemJS 动态导入。
代表方案：single-spa、qiankun、Wujie、micro-app

利用原生 Web Component（如自定义元素、Shadow DOM）封装每个子应用。
适用于需要框架无关、隔离样式的场景。
缺点：浏览器兼容性较旧（IE 不支持），且生态较小。

框架	特点
single-spa	最早的微前端框架，基于路由分发和生命周期管理
qiankun	阿里出品，基于 single-spa 二次封装，支持沙箱、预加载、JS 隔离等特性
Wujie	字节跳动开源，性能更好、体积更小，iframe 与 JS 沙箱混合方案
micro-app	类似 qiankun，支持更灵活的通信与沙箱策略

技术点	说明
路由管理	解决主子应用路由冲突、同步跳转等问题
状态共享	提供全局状态管理方案（如 EventBus、shared store）
样式隔离	避免子应用样式污染主应用（如 Shadow DOM、CSS Module）
JS 运行时隔离	防止子应用篡改全局变量，可使用沙箱机制（Proxy、iframe、snapshot）
子应用生命周期	提供完整生命周期钩子（bootstrap、mount、unmount）支持管理

问题类型	具体问题	解决方案示例
路由冲突	主应用和子应用使用相同的前端路由库	使用 hash 区分，或约定子应用运行在特定前缀路径下
样式污染	子应用样式影响主应用	使用 CSS Modules、BEM 命名规范、Shadow DOM 等方式隔离样式
状态共享混乱	各子应用状态独立	建立中间层（如 Event Bus、Global Store）统一管理
JS 全局污染	多个子应用共用 window 环境	使用 JS 沙箱（如快照沙箱、Proxy 沙箱）隔离运行时环境
构建部署复杂	各子应用使用不同工具链	统一构建标准，或使用模块联邦（Module Federation）
性能开销大	子应用体积大，首次加载慢	使用预加载机制、懒加载、资源 CDN 化