前端微前端框架qiankun和wujie的对比

以下是 qiankun 和 wujie 作为主流微前端框架的对比分析，从技术架构、核心能力、适用场景等多个维度展开：

---

一、技术架构对比

1. qiankun

   • 基础框架：基于 single-spa 扩展，采用 HTML Entry 方式加载子应用，需通过路由匹配激活子应用。
   • 沙箱机制：
     • JS 沙箱：提供快照沙箱（SnapshotSandbox）、代理沙箱（ProxySandbox）等方案，通过代理全局变量实现隔离。
     • CSS 沙箱：支持 strictStyleIsolation（Shadow DOM）和 experimentalStyleIsolation（样式前缀）两种方式，但严格隔离可能导致弹窗样式异常。
   • 路由管理：依赖主应用路由劫持，子应用需适配主应用路由模式（Hash/History），无法同时激活多个子应用。

2. wujie

   • 基础架构：基于 WebComponent 容器 + iframe 沙箱，子应用运行在 iframe 中，通过 Shadow DOM 实现 CSS 隔离，JS 天然隔离于 iframe 上下文。
   • 沙箱机制：
     • JS 沙箱：利用 iframe 的原生隔离能力，无需通过 with 语句或代理劫持，性能接近原生。
     • CSS 沙箱：通过 WebComponent 的 Shadow DOM 实现严格隔离，仅可继承部分 CSS 属性。
   • 路由同步：劫持 iframe 的 history.pushState，将子应用路由同步到主应用 URL 参数，支持多应用同时激活且路由状态保活。

---

二、核心能力对比

能力	qiankun	wujie
子应用保活	不支持	支持（保留状态和路由）
多应用同时激活	不支持	支持
适配成本	高（需改造路由、生命周期等）	低（子应用几乎无需改造）
通信机制	基于 postMessage 和全局状态管理	支持 props 注入、EventBus、window.parent 直接通信
Vite 支持	不支持（需插件改造）	原生支持
性能	JS 沙箱性能损耗较高	接近原生（iframe 无代理开销）
兼容性	依赖 Proxy，不支持 IE11 以下	自动降级至 IE9（替换 Proxy 为 Object.defineProperty）

---

三、适用场景分析

1. qiankun

   • 适用场景：
     • 需要动态加载多个子应用的中大型项目。
     • 团队技术栈统一（如 React/Vue），且能接受较高的子应用适配成本。
   • 局限性：
     • 不支持多应用保活、Vite 子应用，沙箱性能问题在高频交互场景下显著。

2. wujie

   • 适用场景：
     • 快速集成老项目或混合框架（如 Vue2 + Vue3 + React）。
     • 需要同时激活多个子应用或保留子应用状态（如后台管理系统）。
     • 对性能和兼容性要求较高（如兼容 IE9）。
   • 局限性：
     • 弹窗受 iframe 限制（仅降级模式下无法全局覆盖，正常模式下子应用DOM与主应用同源，可以全局展示）。
     • 新推出的框架，更新迭代较慢，可能存在部分问题？

---

四、总结与选型建议

• 选择 qiankun：适合需要动态路由管理和复杂状态共享的大型项目，但需接受较高的改造和维护成本。
• 选择 wujie：适合追求低接入成本、高性能隔离和多应用协作的场景，尤其适合快速迭代和混合技术栈项目。

两种框架的详细实现和案例可参考：无界官方文档、qiankun 官方文档。