qiankun、micro-app、wujie，2025年我们该选谁？

一句话速览

微前端（Micro-Frontends）就是把"一个 Web 页面"拆成"多个可独立开发、独立部署、运行时再拼到一起的小前端应用"，借用了后端微服务的思想，目标是让多团队、多技术栈、多迭代节奏下仍能高速交付一个大产品。

一、核心概念与价值

独立生命周期：每个子应用（Micro-App）拥有从开发→测试→灰度→上线的完整闭环。
技术栈无关：React / Vue / Angular / 纯原生可共存，方便渐进升级。
运行时组合：浏览器端动态加载、卸载、激活子应用，对用户保持"一个域名、一个页面"的体验。
组织映射：一个子应用 ≈ 一个业务域团队，减少跨团队代码冲突。

二、常见架构模式（按 2025 流行度排序）

模式	原理	优点	缺点	适用场景
基座式（主从）	主应用负责路由、壳子、全局状态；子应用被"插"到指定 DOM 节点	社区方案成熟（qiankun、icestark）	基座一旦出问题影响全局	中后台、多菜单系统
路由分发	反向代理（Nginx）或网关按路径转发到不同 HTML 入口	实现极简、天然隔离	页面整页刷新、无法做子应用嵌套	门户、官网拼装
构建时组合	Webpack Module Federation 等在 CI 阶段把子应用打成"远程模块"	运行时性能最好	失去独立部署、需统一构建	高绩效内网工具、包体敏感场景
Web Components	每个子应用封装成自定义元素 `<app-order />`	浏览器原生标准、样式隔离好	改造成本高、老浏览器需 polyfill	组件库、跨框架复用
iframe	最原始、真正的浏览器级隔离	安全/样式 100% 隔离	性能差、通信复杂、SEO 差	第三方不可信内容、低代码嵌入

三、2025 主流技术栈对比（社区综合评分）

框架/方案	实现原理	隔离强度	Vite 支持	通信效率	接入成本	典型场景
qiankun	路由劫持 + Proxy 沙箱	★★★★☆	插件	中（事件）	中	企业后台、阿里系
micro-app	WebComponents + 资源劫持	★★★☆☆	原生	高（标准 API）	低	渐进迁移、Vue3 项目
wujie	iframe 代理渲染	★★★★★	原生	中（postMessage）	极低	金融、政务高敏感
single-spa	生命周期调度	★☆☆☆☆	需插件	自定义	高	深度定制、开源底座
Module Federation	构建时共享	★☆☆☆☆	社区方案	极高（同 bundle）	高	模块生态、字节内部工具

四、30 秒选型决策树（2025 版）

是否需要"零改造"嵌入旧系统？
→ 是：优先考虑 wujie（iframe 代理）或 micro-app（WebComponents）。
是否对"独立部署"强诉求？
→ 是：排除 Module Federation，选 qiankun / micro-app / wujie。
是否对"样式/全局变量"绝对隔离？
→ 是：wujie（iframe）唯一 100% 隔离；qiankun 沙箱可覆盖 90% 场景。
是否已统一使用 Vite + Vue3？
→ 是：micro-app 原生支持最好；qiankun 需装插件。
是否追求"极致性能"且能接受统一构建？
→ 是：Module Federation + Nx Monorepo 是当前性能天花板。

五、关键实现细节

1. 子应用暴露生命周期

所有主流框架都要求子应用 export 三个钩子：bootstrap、mount、unmount。

js 复制代码

// 子应用 main.js
export async function bootstrap() { /* 初始化 */ }
export async function mount(props) { 
  ReactDOM.render(<App/>, props.container) 
}
export async function unmount(props) { 
  ReactDOM.unmountComponentAtNode(props.container) 
}

2. 样式隔离方案

CSS Modules / Scoped CSS
Shadow DOM（micro-app 默认）
动态前缀 + runtime 校验（qiankun strictStyleIsolation）

3. 通信机制

全局事件总线（qiankun 的 initGlobalState）
自定义事件（WebComponents）
postMessage（iframe）
直接 import（Module Federation shared scope）

4. 性能优化

预加载：qiankun prefetch: 'all'；wujie 支持链路预加载。
按需加载：路由匹配时才拉 JS。
公共依赖外置：react、vue 走 shared，避免重复打包。

六、典型踩坑与解决方案

问题	现象	解决
子应用路由冲突	子应用内部使用 BrowserHistory，刷新 404	统一用 MemoryHistory 或基座下发 basename
样式渗透	子应用把全局 `<body>` 字体改坏	开启 ShadowDOM 或 postcss-prefix
重复加载公共包	首页同时加载 react@18 两次	配置 webpack externals + shared
谷歌 SEO 空白	查看源码只有 `<div id="root"></div>`	采用 SSR 基座（qiankun+Next.js）或预渲染
开发环境热更新失效	子应用改代码不刷新	升级 qiankun 2.10+、vite 插件开 `hmr: true`

七、落地 Checklist（照抄即可）

业务拆分：按"用户角色"或"业务域"划分子应用，避免过度拆分（建议 ≤ 8 个）。
技术选型：用上面「决策树」 30 分钟内敲定。
搭建基座：
- 统一登录、菜单、权限、埋点。
- 提供 <micro-app-loader> 容器 + 错误边界。
改造子应用：
- 新增 lifecycle 文件，保持能独立运行（yarn dev 正常起服务）。
- 把路由 basename、publicPath 改成从基座注入。
联调：
- 本地用 nginx 把不同端口聚到一个域名，验证 cookie、sso。
- 开启热更新、sourcemap，确保能断点调试。
上线：
- 各仓库独立 CI/CD，子应用灰度 10% → 50% → 100%。
- 基座记录版本映射表，出问题秒级回滚子应用。

八、2025 趋势速览

双极分化：
a. 「运行时隔离派」qiankun / micro-app / wujie 继续深耕企业级复杂场景；
b. 「模块共享派」Module Federation 与 Monorepo 结合，成为新系统首选。
信创 & 高安全场景推动「iframe 代理」方案回潮，wujie 已在国内多家银行落地。
浏览器新规范「Import Maps」+「Web Components」逐步降低微前端门槛，未来 2 年可能出现浏览器原生微前端 API。

九、写在最后

微前端不是银弹，却是"团队规模化 + 技术栈遗留 + 高速交付"三者交集下的最优解。抓住"独立部署""渐进升级""运行时组合"三大核心，再按决策树选定技术栈，基本可以 2 周内完成从 0 到 1 的验证。