微前端框架选型指南
一、写在前面
微前端架构为大型前端系统提供了分而治之的能力，不同团队可以独立开发、部署和维护各自的模块。然而，当前市面上存在多种微前端框架（如 Qiankun、Wujie、micro-app、Hel、Emp 等），选型不当将导致项目架构臃肿、维护成本上升。
本文将从技术机制、接入方式、工程复杂度、使用场景等角度，提供一份通用的微前端框架选型指南，帮助技术负责人和架构师做出科学决策。
二、常见微前端框架概览
| 框架名 | 出品方 | 推出时间 | 技术机制 | 特点关键词 |
|---|
| Qiankun | 阿里蚂蚁金服 | 2019 | single-spa + Proxy 沙箱 | 成熟稳定 / 生命周期完整 / 社区广 |
| Wujie | 腾讯 | 2022 | iframe + JS 沙箱 | 快速集成 / 极致兼容 / 零改造 |
| micro-app | 京东 | 2021 | Proxy + DOM 劫持 | 极致轻量 / 并发挂载 / SSR 友好 |
| Hel | 美团 | 2021 | 模块注册 + 动态加载 | 组件级共享 / 适配超大系统 |
| Emp | 腾讯 | 2021 | Webpack Module Federation 封装 | 工程化强 / 远程模块 / 模块共享 |
| ice.js | 阿里冰山团队 | 2022 | MF 集成 + 冰山工程体系 | 新项目一体化 / 云端构建 |
三、核心选型维度
1. 接入成本 vs 系统改造能力
| 项目特点 | 推荐框架 | 理由 |
|---|
| 老系统改造、技术债多 | Wujie | iframe 零改造接入，最少侵入 |
| 项目可控、统一栈 | Qiankun / micro-app | 改造可控，支持生命周期 / 状态共享 |
| 跨团队组件共享频繁 | Hel | 支持细粒度模块共享，动态替换能力强 |
2. 性能 & 用户体验要求
| 诉求 | 推荐框架 | 理由 |
|---|
| 首屏加载快 | micro-app | 支持子应用并发挂载，预加载机制优秀 |
| 高并发页面 / 动态替换 | Hel | 模块粒度复用，热更新效率高 |
| 对性能容忍度高 | Wujie | iframe 性能略低，但换取兼容性最大化 |
3. 工程化与规范化能力
| 工程诉求 | 推荐框架 | 理由 |
|---|
| 有脚手架 / 自动注册能力 | Emp | Module Federation 封装完善 |
| 统一构建 / 发布平台 | ice.js | 云端构建一体化，适合新平台搭建 |
| 跨仓库依赖复用 | Hel | 支持模块单独注册、共享、远程引用 |
四、典型场景推荐
| 场景类型 | 推荐框架组合 | 说明 |
|---|
| 老系统接入门户 | 主应用 Qiankun + 子应用 Wujie | 主控清晰、子系统无感升级 |
| OA 或中后台平台 | micro-app 或 Qiankun | 支持并发挂载 / 生命周期控制 |
| 组件市场或低代码平台 | Hel | 模块级注册、动态热更新友好 |
| 多 BU / 多子公司平台 | Emp + Hel | 跨团队复用 / 工程自动化需求强 |
五、总结建议
- ✅ 先评估改造成本：是否允许修改子系统代码？如果不允许，Wujie 是唯一选择。
- ✅ 再考虑性能和体验：追求首屏体验 → micro-app，动态能力强 → Hel。
- ✅ 重视团队工程能力：强工程团队可用 Emp 构建微模块架构。
- ✅ 统一平台建议用 Qiankun：配合动态 manifest，治理多个子系统最稳健。
六、一句话总结
如果你想“快速挂接老系统”，用 Wujie；
如果你想“控制子系统生命周期”，用 Qiankun；
如果你要“性能与并发体验”，用 micro-app；
如果你追求“细粒度动态模块化”，用 Hel；
如果你是“平台工程搭建者”，用 Emp + ice.js。
如需获得定制化推荐（结合你的业务模块、部署方式、团队协作模型），可参考具体使用场景进行拆解和匹配框架能力。
