微前端总结
# 一、什么是微前端
提示
Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. -- Micro Frontends
微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。
微前端架构具备以下几个核心价值：
技术栈无关
主框架不限制接入应用的技术栈，微应用具备完全自主权
独立开发、独立部署
微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新
增量升级
在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略
独立运行时
每个微应用之间状态隔离，运行时状态不共享
微前端架构旨在解决单体应用在一个相对长的时间跨度下，由于参与的人员、团队的增多、变迁，从一个普通应用演变成一个巨石应用(Frontend Monolith)后，随之而来的应用不可维护的问题。这类问题在企业级 Web 应用中尤其常见。
# 一、微前端总体对比表
| 对比项 | Wujie | qiankun | micro-app | iframe |
|---|---|---|---|---|
| 隔离性 | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 性能 | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| 路由同步 | ✅ 强 | ✅ 中 | ✅ 强 | ❌ 弱 |
| 通信机制 | ✅ 简单（bus） | ✅ initGlobalState | ✅ data + event | ❌ postMessage |
| 样式隔离 | ✅ CSSScope + iframe | ✅ scopedCSS | ✅ ShadowDOM | ✅ 天然 |
| 兼容性 | ✅ 最强 | ✅ 较强 | ⚠️ 新浏览器友好 | ✅ 强 |
| 学习成本 | ⚠️ 中等偏高 | ✅ 低 | ⚠️ 中 | ✅ 最低 |
| 适用场景 | 大型多系统、跨栈整合 | 传统项目集成 | 新架构、高性能项目 | 简单隔离场景 |
| 框架 | 核心理念 | 技术实现 | 优点 | 缺点 |
|---|---|---|---|---|
| Qiankun | 基于 single-spa 的企业级微前端框架 | 沙箱隔离（Proxy + snapshot）、生命周期管理 | 稳定成熟、生态好、接入简单、文档完善 | 启动性能较慢、JS 执行隔离有限（快照沙箱容易冲突）、对样式隔离支持一般 |
| micro-app | 借鉴 WebComponent + 自研沙箱 | 原生 customElements 封装子应用 | 性能好、原生隔离强（CSS/JS 都较好）、支持多种加载模式、框架无关 | 文档和社区相对较小，兼容性略差（某些旧浏览器问题） |
| Wujie（无界） | “iframe + 微内核” 模式（沙箱通信复用 iframe） | iframe 做运行隔离 + 通信桥接机制 | 真隔离（CSS/JS/DOM）、安全性最高、子应用无污染、支持 React/Vue3 | 首屏性能略差（iframe 加载），嵌套复杂度高，主子通信逻辑偏重 |
# 二、架构原理对比（简述）
| 框架 | 隔离机制 | 通信机制 | 加载方式 |
|---|---|---|---|
| Qiankun | JS：Proxy 沙箱 CSS：手动作用域 or BEM | props + globalState | HTML entry 拉取 |
| micro-app | JS：Proxy 沙箱 + iframe 隔离选项 CSS：Shadow DOM + scoped | window.microApp.dispatch | script + WebComponent |
| Wujie | 完全 iframe 级隔离 通信：postMessage + Bridge 桥接 | 主子通过 wujie.bus 通信 | iframe 懒加载 + 预加载 |
| 框架 | 实现机制 | 说明 |
|---|---|---|
| iframe | 浏览器原生隔离 | 每个子应用运行在独立窗口上下文中，天然隔离 DOM、JS、CSS |
| qiankun | 基于 single-spa + JS 沙箱 | 子应用 HTML 解析、JS 执行在 Proxy 环境中，通过劫持 window 实现沙箱 |
| micro-app | CustomElement + Proxy 沙箱 | 子应用挂载为自定义元素（<micro-app>），利用 ShadowDOM + 沙箱实现隔离 |
| EMP | Webpack Module Federation | 构建时暴露模块，运行时动态加载（非真正运行时隔离） |
| 无界（wujie） | iframe + main-app DOM 复用 + 沙箱 | 子应用运行在 iframe 的 document 中，但共享主应用的路由和上下文 |
# 三、实际体验总结
# ✅ 1. Qiankun（最成熟）
优点：
- 上手最快，文档完整。
- 生态成熟，社区问题多有解答。
- 与 Vue、React 项目无缝衔接。
缺点：
- 性能不算最优，切换子应用时开销大。
- 沙箱隔离有边界，部分全局依赖容易冲突。
建议：适合已有系统改造，或者需要快速搭建微前端框架的团队。
适用场景：大型 B 端系统，兼容 Vue2/React 的老项目改造
# ✅ 2. micro-app（性能与隔离兼顾）
优点：
- 原生 WebComponent 机制，隔离好、加载快。
- 支持 keep-alive、预加载、iframe 混用等优化。
- 可与任意框架（甚至纯 HTML）集成。
缺点：
- 部分高级特性文档不详细。
- 沙箱兼容性略逊于 qiankun。
建议：适合新系统、跨框架场景（React+Vue 共存），对性能敏感的项目。
适用场景：追求性能、兼容性要求高、希望框架无关的新项目
# ✅ 3. Wujie（隔离最彻底）
优点：
- iframe 真隔离，无需担心样式、脚本冲突。
- 通信机制灵活、安全性强。
- 支持多实例并存。
缺点：
- iframe 加载略慢，影响首屏。
- 子应用间共享资源困难。
- 开发体验复杂。
建议：适合安全性要求高（如银行、政务、内网）的项目。
适用场景：高安全场景（如金融系统）、多团队独立交付、极高隔离要求
# 四、选择建议（按项目类型）
| 项目类型 | 推荐框架 | 理由 |
|---|---|---|
| 旧项目微前端改造（Vue2/React） | Qiankun | 稳定易迁移 |
| 新项目 + 追求性能 | micro-app | 快速加载 + 隔离良好 |
| 金融/政务 + 高安全 | Wujie | 真隔离、防污染 |
| 多框架共存（Vue、React、Angular） | micro-app | 框架无关性强 |
# 五、总结（简短版）
- Qiankun：基于 single-spa，生态成熟，适合老系统改造，但隔离性一般。
- micro-app：采用 WebComponent 技术，性能更好、隔离更强，适合新项目。
- Wujie：利用 iframe 实现彻底隔离，安全性最高，适合高安全场景。 实际选择时我会根据性能、安全性和团队框架兼容性来综合判断。
# 二、路由
虚拟路由系统与浏览器的路由行为一致，它通过自定义 location 和 history 等核心路由 API，重写了 popState 和 hashChange 事件，拦截路由导航和事件，并提供了一系列自定义 API，模拟了在浏览器环境下的 Web 应用程序的渲染、跳转和返回等路由行为。子应用程序在这个虚拟路由系统中运行，与基座应用程序的路由相互隔离，从而避免相互影响，并增强了子应用程序与基座应用程序之间的交互能力。通过虚拟路由系统，基座应用程序可以方便地获取子应用程序的路由信息并控制子应用程序的跳转，子应用程序的路由信息会作为参数同步到浏览器地址上。此外，虚拟路由系统还提供了许多功能，帮助开发人员提高工作效率。
| 框架 | 实现方式 | 特点 |
|---|---|---|
| iframe | 独立路由系统 | 每个 iframe 拥有自己的 URL，不与主应用共享 |
| qiankun | 路由劫持（popstate、hashchange） | 主应用统一控制路由，通过 activeRule 匹配加载子应用 |
| micro-app | 独立路由 + 同步机制 | 子应用运行在 ShadowDOM 中，使用 micro-app-router 实现与主路由同步 |
| EMP | 路由由宿主控制 | 模块导入后挂载到指定路由组件，通常依赖宿主 React/Vue Router |
| 无界（wujie） | iframe 内路由同步 | 主子应用路由同步机制强，可使用 sync 属性控制路由策略 |
✅ 路由机制总结：
qiankun 和 micro-app 是运行时动态加载型；
EMP 是构建期共享型；
无界 混合模式兼顾灵活性和隔离性。
# 三、web components
webcomponents相关文章 (opens new window)
- 组件库开发 可以用于构建大型的组件库，如UI组件库。像按钮、表单、菜单等组件都可以作为Web Component进行开发。这样的组件库可以被不同的项目复用，提高开发效率。例如，一个公司可以开发一套内部使用的UI组件库，包含各种风格统一的组件，供各个产品团队使用。
- 微前端架构 在微前端架构中，每个微应用可以被封装成一个Web Component。不同的团队可以独立开发自己的微应用，然后将它们组合成一个完整的应用。例如，一个电商网站可以有产品展示微应用、购物车微应用、用户登录微应用等，这些微应用可以通过Web Component的方式集成在一起。
| 框架 | 是否基于 WebComponent | 特点 |
|---|---|---|
| iframe | 否 | 浏览器原生标签，不需要组件封装 |
| qiankun | 否（基于容器 DOM） | 手动指定挂载点 container |
| micro-app | ✅ 是 | 每个子应用是一个独立的 <micro-app> 元素 |
| EMP | ❌ 否 | 模块导出导入，走构建链路 |
| 无界 | ✅ 混合支持 | 子应用 DOM 可通过 ShadowDOM 管理 |
✅ micro-app 在这一点最现代化，基于 Web Components 天然封装性强。
# 四、如何样式隔离
| 框架 | 隔离方式 | 隔离级别 |
|---|---|---|
| iframe | 浏览器原生隔离 | ⭐⭐⭐⭐（最彻底） |
| qiankun | ScopedCSS + ShadowDOM（可选） | ⭐⭐（部分隔离） |
| micro-app | ShadowDOM + CSSScope + 沙箱 | ⭐⭐⭐⭐（稳定高效） |
| EMP | 无（依赖工程约定） | ⭐（需 BEM 或 CSS Modules） |
| 无界 | iframe + CSSScope 混合 | ⭐⭐⭐⭐（灵活可控） |
- ✅ 若项目有多团队多技术栈，micro-app / 无界 / iframe 隔离效果最佳。
- BEM（Block Element Modifier）约定项目前缀
- css-Modules 打包时生成不冲突的选择器名
- Shadow Dom 真正意义上的隔离
- css-in-js
<div id="shadow"></div>
<script>
let shadowDOM = shadow.attachShadow({mode:"close"}); // 外界无法访问shadow dom 其中shadow相当于document.getElementById('shadow').attachShadow
let pElm = document.createElement("p");
pElm.innerHTML = "hello world";
let styleElm = document.createElement("style");
styleElm.textContent = `
p{
color:red;
}
`
shadowDom.appendChild(styleElm);
shadowDOM.appendChild(pElm);
</script>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 五、如何通讯
- 基于url进行数据传递，但传递消息能力弱
- 基于customEvent实现通讯
- 基于props进行主子组件通信
- 使用全局变量、Redux进行通讯
| 框架 | 通信方式 | 说明 |
|---|---|---|
| iframe | postMessage | 原生 API，但编码麻烦，异步 |
| qiankun | initGlobalState() 全局共享状态 | 类似 Redux，可监听变化 |
| micro-app | data 属性 + 自定义事件 + 全局通信 | 支持双向绑定风格，简单易用 |
| EMP | 直接 import 共享模块 | 构建时共享依赖，实时同步数据 |
| 无界（wujie） | bus 通信机制 | 主子应用共享一个通信总线 |
- ✅ micro-app / 无界 → 通信简洁、响应式；
- ✅ EMP → 工程体系内最优（无需运行时通信）。
更多关于微前端的相关介绍，推荐大家可以去看这几篇文章：
- Micro Frontends (opens new window)
- Micro Frontends from martinfowler.com (opens new window)
- 可能是你见过最完善的微前端解决方案 (opens new window)
- 微前端的核心价值 (opens new window)
相关配置介绍可以查看 webpack 相关文档 (opens new window)。
# 附录、实现方案对比
# qiankun方案
# 🧩 一、qiankun 是什么
qiankun 是一个基于 single-spa 实现的微前端框架， 核心理念是：让多个独立运行的前端应用（不同技术栈）在同一个主应用中平滑共存。
它的核心目标：
- 子应用独立开发、独立构建、独立部署；
- 主应用统一加载、注册、通信；
- 技术栈无关（Vue、React、Angular 均可）。
# ⚙️ 二、qiankun 的核心原理
| 模块 | 实现思路 |
|---|---|
| 运行时调度 | 基于 single-spa，对路由进行劫持，根据激活规则加载子应用 |
| 资源加载 | 拦截子应用 HTML，解析出 JS/CSS 动态注入（支持预加载） |
| JS 隔离（沙箱） | 通过 Proxy + Snapshot 沙箱隔离子应用全局变量 |
| 样式隔离 | ShadowDOM（实验）或 scoped CSS 前缀实现样式作用域控制 |
| 通信机制 | 提供 initGlobalState 实现主子应用数据同步 |
| 生命周期管理 | 提供 bootstrap、mount、unmount 生命周期钩子 |
| 路由机制 | 子应用独立路由系统，可与主应用 hash/history 同步 |
# 🧠 三、qiankun 的优点（优势）
| 优点方向 | 说明 |
|---|---|
| ✅ 1. 成熟稳定、社区庞大 | 阿里团队维护，生态最完善，文档详尽，应用广泛（阿里云、钉钉、菜鸟等都在用）。 |
| ✅ 2. 支持多技术栈 | 主子应用可分别使用 Vue、React、Angular 等不同框架，互不影响。 |
| ✅ 3. 接入简单、低侵入 | 子应用几乎不用修改业务代码，只需暴露生命周期钩子。 |
| ✅ 4. 隔离机制完善 | 支持 JS 沙箱（Proxy + Snapshot）和 CSS 隔离，防止样式、全局变量冲突。 |
| ✅ 5. 生命周期完整 | 提供 bootstrap、mount、unmount 生命周期，可精细控制加载卸载行为。 |
| ✅ 6. 支持资源预加载 | 子应用在未激活前可提前加载资源，提高切换性能。 |
| ✅ 7. 数据通信机制清晰 | 官方 initGlobalState 支持主子、子子应用通信。 |
| ✅ 8. 可扩展性强 | 支持手动加载子应用、自定义加载策略、预加载策略、错误边界等。 |
# ⚠️ 四、qiankun 的缺点（局限性）
| 缺点方向 | 说明 |
|---|---|
| ❌ 1. 启动性能较差 | 每个子应用需独立解析、加载、执行 HTML、CSS、JS，首屏加载速度慢。 |
| ❌ 2. JS 沙箱性能开销大 | Proxy / Snapshot 沙箱在频繁 mount/unmount 时性能损耗明显。 |
| ❌ 3. 样式隔离不彻底 | scopedCSS 对第三方库的全局样式（如 ElementUI）隔离效果有限。 |
| ❌ 4. 多应用间共享依赖困难 | 子应用各自打包，导致 React/Vue 等重复加载，占用体积。 |
| ❌ 5. 调试复杂 | 动态加载子应用资源，SourceMap 定位困难。 |
| ❌ 6. 跨域问题需手动配置 | 子应用部署到不同域名时，需要设置 CORS 或代理。 |
| ❌ 7. SSR 支持差 | qiankun 主要面向 SPA 架构，SSR 支持几乎为零。 |
| ❌ 8. 与现代构建工具结合有限 | 对 Vite、ESM 构建生态支持较弱，依赖 Webpack 构建体系。 |
# 🔍 五、与其他微前端框架对比
| 对比项 | qiankun | micro-app | Wujie | EMP |
|---|---|---|---|---|
| 实现机制 | single-spa + 沙箱 | WebComponent + 沙箱 | iframe + 沙箱 | Module Federation |
| 隔离性 | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| 性能 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 技术栈兼容 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| 样式隔离 | scopedCSS | Shadow DOM | iframe | 无 |
| 路由控制 | ✅ 强 | ✅ 强 | ✅ 强 | ⚠️ 弱 |
| 通信机制 | initGlobalState | eventCenter | bus | JS 调用 |
| 构建依赖 | Webpack | 任意 | 任意 | Webpack5 |
| 接入复杂度 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| SSR 支持 | 弱 | 一般 | 弱 | 弱 |
# 🧭 六、适用场景建议
✅ 推荐使用 qiankun 的情况：
- 多团队并行开发的中大型平台；
- 主子应用使用不同框架；
- 需要稳定、成熟、社区完善的方案；
- 对安全隔离要求中等。
⚠️ 不推荐使用 qiankun 的情况：
- 对性能敏感（如首屏时间要求很高）；
- 需要高频切换子应用；
- 希望共享依赖或支持 Vite；
- 对 SSR / Node 渲染有要求。
# 💬 七、一句话总结
qiankun 是最稳定的“运行时微前端”代表： 成熟、兼容性强、生态完善， 但性能与现代工具链支持略显落后。 适合“多团队 + 多框架 + 稳定平台”的企业级项目。
# micro-app 方案
# 🧩 一、micro-app 是什么
micro-app 是一个基于 Web Components 规范实现的微前端框架。
它通过创建一个自定义标签
<micro-app>来加载子应用，实现「组件化的微前端」。
示例：
<micro-app name="sub-vue" url="http://localhost:8080/"></micro-app>
1
特点：
- 使用自定义元素包裹子应用；
- 子应用运行在虚拟沙箱中；
- 支持样式、JS、DOM 的隔离；
- 主子应用通信简单；
- 无需 iframe，也不依赖构建时联邦。
# ⚙️ 二、micro-app 的核心实现原理
| 模块 | 原理说明 |
|---|---|
| WebComponent 封装 | 每个子应用都被包裹在一个自定义标签 <micro-app> 中 |
| JS 沙箱 | 通过 Proxy + iframe window 模拟实现 JS 隔离环境 |
| 样式隔离 | 使用 Shadow DOM + scoped 样式前缀 实现 CSS 隔离 |
| DOM 隔离 | 每个子应用独立虚拟 DOM 树，与主应用隔离 |
| 资源加载 | 拦截子应用 HTML、JS、CSS 请求，重写路径并动态注入 |
| 通信机制 | 基于全局事件和数据总线（eventCenter）实现主子通信 |
| 路由模式 | 支持独立路由，也支持主子同步（hash/history） |
# 🧠 三、micro-app 的优点（优势）
| 优点方向 | 说明 |
|---|---|
| ✅ 1. 高性能 | - 子应用直接运行在主页面上下文，无 iframe 进程切换开销 - 基于 Shadow DOM 的样式隔离，避免全局污染 - 可复用缓存，实现“秒开”体验 |
| ✅ 2. 高兼容性 | - 支持 Vue、React、Angular、小程序 Web 化项目 - 对旧项目接入友好，接入成本低 |
| ✅ 3. 低侵入性 | - 子应用几乎无需改造 - 不需要调整 webpack 构建配置 |
| ✅ 4. 沙箱隔离完善 | - JS 通过 Proxy 实现独立作用域 - 样式隔离通过 Shadow DOM - DOM 挂载点独立，不会污染主应用 |
| ✅ 5. 通信机制灵活 | - 内置全局事件中心（eventCenter） - 主子可双向通信（emit/on） |
| ✅ 6. 路由可控性强 | - 子应用可使用自己的路由系统 - 也可与主应用路由同步切换 |
| ✅ 7. 生命周期丰富 | - 提供完整的生命周期钩子（mount/unmount/hidden/show） - 可实现缓存、keep-alive 等功能 |
| ✅ 8. 支持 SSR / KeepAlive | - 子应用可缓存 DOM、快速恢复 - 支持 SSR 加载场景（通过 DOM 注入） |
# ⚠️ 四、micro-app 的缺点（局限性）
| 缺点方向 | 说明 |
|---|---|
| ❌ 1. 沙箱开销较高 | - Proxy 沙箱模拟 window，存在性能损耗 - 大型子应用加载时 CPU 开销明显 |
| ❌ 2. 不适合旧浏览器 | - 依赖 Web Components、Proxy、Shadow DOM 等新特性 - 需要现代浏览器（Chrome 60+） |
| ❌ 3. 调试复杂度高 | - 子应用运行在虚拟环境中，调试变量和作用域不直观 |
| ❌ 4. 跨域问题需手动处理 | - 子应用资源（JS/CSS）跨域时需配置 CORS 或代理 |
| ❌ 5. 初次加载速度略慢 | - 子应用首次加载需动态解析 HTML 并注入脚本 - 解析过程相对 qiankun 稍慢 |
| ❌ 6. SSR 支持不完善 | - 官方支持有限，需配合定制渲染逻辑 |
| ❌ 7. 子应用对全局样式、window 对象操作仍需规范 | - 若子应用直接修改全局样式、注册全局变量，可能引发冲突 |
# 🔍 五、与其他微前端框架对比
| 对比项 | micro-app | qiankun | Wujie | EMP |
|---|---|---|---|---|
| 实现机制 | WebComponent + Proxy 沙箱 | single-spa + Proxy 沙箱 | iframe + 沙箱混合 | Module Federation |
| 隔离性 | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| 性能 | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 架构粒度 | 应用级 | 应用级 | 应用级 | 模块级 |
| 通信方式 | eventCenter | initGlobalState | bus | JS 调用 |
| 样式隔离 | Shadow DOM | scopedCSS | iframe/Scoped | 无 |
| 路由支持 | 强 | 强 | 强 | 弱 |
| SSR 支持 | 一般 | 一般 | 弱 | 弱 |
| 兼容性 | 现代浏览器 | 最强 | 中等 | 同栈项目 |
| 生态社区 | 活跃 | 最成熟 | 稳定 | 新兴 |
# 🧭 六、适用场景建议
✅ 推荐使用 micro-app 的情况：
- 中大型前端平台，主子项目技术栈相似；
- 追求良好的性能与隔离性平衡；
- 希望低成本接入；
- 需要缓存、秒开、灵活通信。
⚠️ 不推荐使用的情况：
- 需要兼容 IE 或老浏览器；
- 子应用很大（沙箱性能损耗明显）；
- 对安全、隔离要求极高；
- 对 SSR 有强需求的项目。
# 💬 七、一句话总结
micro-app 是最接近“前端原生实现”的微前端框架： 以 Web Components 为核心，兼顾性能、隔离、易用性， 适合现代浏览器、单页架构和多团队并行开发场景。
# EMP 方案
# 🧩 一、EMP 是什么
EMP（Easy Micro Frontend Platform） 是一个基于 Webpack5 Module Federation 封装的微前端框架， 它不是运行时框架（如 qiankun、micro-app），而是构建时方案。
简单理解：
它不通过 iframe 或沙箱隔离，而是通过 webpack 构建配置，让多个独立应用在构建阶段共享模块、动态引入，实现「真正意义上的模块级解耦」。
# ⚙️ 二、EMP 的核心原理
| 模块 | 实现方式 |
|---|---|
| 核心机制 | 基于 Webpack 5 的 Module Federation |
| 共享模块 | 多个子应用共享公共依赖（如 React/Vue/Element 等） |
| 模块暴露 | 子应用通过 exposes 暴露组件/模块 |
| 模块加载 | 主应用或其他子应用通过 remotes 动态引入这些暴露模块 |
| 运行机制 | 运行时通过 remoteEntry.js 动态加载远程模块（懒加载） |
| 构建优化 | 多项目间公共依赖统一打包、版本对齐 |
| 部署策略 | 可独立部署，每个应用发布 remoteEntry.js 到 CDN |
# 🧠 三、EMP 的优点（优势）
| 优点方向 | 说明 |
|---|---|
| ✅ 1. 性能更高（构建级共享） | - 基于构建时的模块共享，而非运行时沙箱 - 主子应用间共享依赖包，减少重复打包与加载 - 大幅降低 bundle 体积和加载时间 |
| ✅ 2. 真正的模块级复用 | - 允许在不同项目间直接引入远程模块或组件 - 实现「组件级」微前端（比 qiankun 的“子系统级”更细粒度） |
| ✅ 3. 无运行时性能损耗 | - 不依赖 iframe、沙箱或 WebComponent - 直接运行在同一执行上下文中，无上下文切换成本 |
| ✅ 4. 开发体验好 | - 不需要子应用改造路由、生命周期等 - 对于 Vue/React 项目几乎零侵入 |
| ✅ 5. 热更新友好（HMR 支持） | - 支持模块热替换（Hot Module Replacement） - 子模块变更无需整体构建 |
| ✅ 6. 独立部署 + 自动依赖管理 | - 每个子应用仍可独立部署 - 通过 CDN 发布远程模块，实现灵活组合 |
| ✅ 7. 跨团队协作效率高 | - 不同团队独立开发、共享组件 - 中台或组件库复用能力极强 |
| ✅ 8. 支持多框架（Vue/React/Angular） | - EMP 提供 Vue、React 双栈模板 - 混合栈项目可互相引用模块 |
# ⚠️ 四、EMP 的缺点（局限性）
| 缺点方向 | 说明 |
|---|---|
| ❌ 1. 强依赖 Webpack 5 | - 只能在 Webpack5 环境下运行 - 对 Vite、Rollup 等生态兼容性差 |
| ❌ 2. 对版本一致性敏感 | - Module Federation 对依赖版本要求严格（例如 React17 vs 18） - 不一致可能导致运行时冲突或重复加载 |
| ❌ 3. 首次加载依赖链复杂 | - 动态加载远程模块需额外请求 remoteEntry.js - 远程资源较多时首屏性能可能下降 |
| ❌ 4. 部署/发布流程复杂 | - 需要维护各应用 remoteEntry.js 地址 - CDN 更新策略、缓存控制需小心处理 |
| ❌ 5. 安全与隔离性较弱 | - 所有模块在同一 JS 上下文执行 - 若子模块污染全局变量会影响整个系统 |
| ❌ 6. 调试难度较高 | - 动态加载远程模块时 SourceMap 定位困难 - 出错堆栈可能混合多个项目的模块路径 |
| ❌ 7. 不支持旧项目 | - Vue2 + Webpack4 等老项目接入需迁移成本高 |
| ❌ 8. SSR 支持较弱 | - Module Federation 对 Node SSR 环境支持有限（需额外处理远程依赖） |
# 🔍 五、与其他微前端框架对比
| 对比项 | EMP | qiankun | micro-app | Wujie |
|---|---|---|---|---|
| 技术类型 | 构建时（Module Federation） | 运行时（沙箱） | 运行时（WebComponent） | 混合型（iframe+沙箱） |
| 隔离性 | 弱（共享上下文） | 中等 | 强 | 很强 |
| 性能 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 架构粒度 | 模块级 | 应用级 | 应用级 | 应用级 |
| 通信方式 | JS 直接调用 | 全局状态 | 自定义事件 | bus |
| 构建复杂度 | 中等 | 低 | 中 | 高 |
| SSR 支持 | 较弱 | 一般 | 一般 | 较弱 |
| 适用场景 | 模块复用、中后台组件共享 | 多系统整合 | 多应用灵活挂载 | 大型隔离系统 |
# 🧭 六、适用场景建议
✅ 推荐使用 EMP 的场景：
- 同公司、同技术栈的多个中后台项目；
- 需要高效共享业务组件、模块；
- 希望减少重复打包、提高构建速度；
- 前后端部署体系可控（CDN / 内部网）。
⚠️ 不推荐使用 EMP 的场景：
- 多技术栈混合（Vue + React）；
- 旧项目（Webpack <5）；
- 安全性要求极高；
- SSR 或 Node 同构项目。
# 💬 七、一句话总结
EMP 是构建时微前端的代表， 主打“高性能模块共享”和“组件级微前端”， 适合前端多项目、多团队共享组件的企业场景， 但不适合跨栈、隔离性要求高的系统。
# 无界（Wujie） 方案
# 🧩 一、Wujie（无界）是什么？
无界（Wujie）是一个高性能、低侵入的微前端框架， 结合了
iframe的安全隔离特性和qiankun的高性能路由机制。
它采用：
- iframe 容器作为基础隔离环境，
- 同时复用主应用的 DOM、JS 上下文和资源，
- 并通过“主子路由同步 + 沙箱 + 通信总线”来实现性能和兼容的平衡。
# ⚙️ 二、Wujie 的核心实现原理
| 模块 | 实现思路 |
|---|---|
| 渲染隔离 | 使用 iframe 内的 document 作为执行上下文，但不重新加载浏览器上下文（不新开进程） |
| 脚本执行 | 注入沙箱（Proxy）隔离 window / document 的访问 |
| 样式隔离 | 通过 ScopedCSS + iframe 实现双层隔离 |
| 路由管理 | 主子应用路由同步（可选择独立或同步） |
| 通信机制 | 主子共享一个全局 event-bus，可双向通信 |
| 缓存机制 | 子应用可缓存 DOM，返回时秒开（可 keep-alive） |
# 🧠 三、Wujie 的优点（优势）
| 优点方向 | 具体说明 |
|---|---|
| ✅ 1. 高性能 | - 子应用使用 iframe document 但共享资源，不重新加载 - 切换应用时几乎“秒开” - 支持 DOM 缓存与快照恢复 |
| ✅ 2. 强兼容性 | - 同时兼容 Vue2/Vue3/React/Angular 等多栈 - 适用于老项目集成（兼容低版本浏览器） |
| ✅ 3. 隔离性强 | - 基于 iframe document 实现“半隔离”：CSS、JS、DOM 均隔离 - 但能访问宿主上下文变量（受控暴露） |
| ✅ 4. 路由同步灵活 | - 可选择“独立路由模式”或“同步主应用路由” - 支持 hash/history 两种方式共存 |
| ✅ 5. 通信简单 | - 内置全局通信总线（bus） - 支持双向调用，如 window.$wujie.bus.emit/on |
| ✅ 6. 支持 keep-alive 缓存 | - 子应用首次加载后可缓存 DOM 状态 - 返回时直接渲染缓存节点，无需重新加载 |
| ✅ 7. 更低侵入性 | - 子应用几乎无需改造 - 不需要改 webpack 配置、不需修改构建命令 |
| ✅ 8. 安全性更高 | - 代码在 iframe 中执行，不直接污染主应用环境 - 可控制脚本注入和资源权限 |
# ⚠️ 四、Wujie 的缺点（局限性）
| 缺点方向 | 具体说明 |
|---|---|
| ❌ 1. 实现复杂度高 | 内部机制比 qiankun 复杂（iframe + 沙箱混合），调试难度大。 |
| ❌ 2. 社区生态较小 | 相比 qiankun、micro-app，社区资料和插件支持少。 |
| ❌ 3. Debug 不友好 | 子应用运行在 iframe 内，浏览器调试需要切换上下文。 |
| ❌ 4. 与 iframe 相关的限制仍存在 | 例如跨域 cookie、localStorage 等隔离问题仍需特殊处理。 |
| ❌ 5. 初次加载仍慢于纯运行时方案 | 第一次加载子应用仍需创建 iframe document，略慢于 micro-app。 |
| ❌ 6. SSR 支持不完善 | 无界目前主要面向 SPA 模式，对 SSR 支持较弱。 |
| ❌ 7. 依赖 DOM 操作较多 | 内部大量动态注入脚本和样式，在复杂场景下可能带来性能波动。 |
# 🧭 五、适用场景建议
✅ 推荐使用 Wujie 的情况：
- 企业级后台 / 平台类系统；
- 子应用较多（>5），且技术栈不统一；
- 需要较强隔离但不想牺牲性能；
- 希望复用现有系统，无需大改动。
⚠️ 不推荐使用 Wujie 的情况：
- 追求最极致性能（首屏极短）；
- 简单内部系统（只有2~3个子项目）；
- 希望 SSR 同构渲染；
- 团队人手有限（调试维护成本较高）。
# 💬 六、总结一句话
Wujie 是介于
iframe与qiankun之间的“平衡型微前端框架”：拥有 iframe 的安全性 + qiankun 的性能与灵活性， 适合大型、多技术栈、长生命周期的前端平台化项目。
上次更新: 2025/11/25, 03:24:47