v2.0 与现状
基于 wujie v2（2026-06 复活） · 核于 2026-07
速查
- wujie v1 线（2021~2023） 迭代到 v1.0.29 后长期沉寂，一度被认为停更
- 2026-06 发布 v2.0，官方称**「全新空白同域 iframe 沙箱」，并连发 4 版复活**（v2.0.0 → v2.0.1 → v2.0.2 → v2.1.0，全在 2026-06）
- v2.0 沙箱内核重构的核心收益：支持浏览器前进后退（子应用 iframe 路由正确进入浏览器历史栈），修了 v1 时代 iframe 路由与浏览器历史割裂的老痛点
- v2.1.0（2026-06-15） 关键变更：内联事件处理器在子应用作用域执行、修复异步加载 CSS 重复插入、修复子应用刷新
destroy竞态内存泄漏、新增refreshAppAPI（子应用全量重建刷新） - 选型定位：wujie = 隔离最强（iframe 物理隔离）+ Vite/ESM 原生友好 + 保活预加载秒开，甜区是**「复杂子应用 + 要最强隔离 + Vite 主力」**
- 与 qiankun 分野：qiankun 软沙箱省内存但隔离弱、ESM 难；wujie 物理隔离最强、Vite 友好但有 iframe 开销
- 与 micro-app 分野：都走自定义元素用法，但 wujie 默认 iframe 物理沙箱（最强、最重），micro-app 默认 with/Proxy 软沙箱（更轻、也提供 iframe 模式）——详见其叶（前向引用）
- 局限：每子应用一个 iframe 的内存/启动开销、同域约束（
location操作走window.$wujie.location）、弹窗需处理 Shadow DOM 逃逸、第三方全局变量在闭包里需显式挂 window - 一句话现状：2026-06 v2.0 复活、月内连发 4 版，iframe 路线在「隔离 + Vite」两个维度上仍是独一档
一、v2.0：全新空白同域 iframe 沙箱
wujie 的 v1 线在 2021~2023 年间迭代到 v1.0.29，之后长期沉寂——社区一度把它归入「停更」阵营。转机在 2026-06：wujie 发布 v2.0，官方定调为**「全新空白同域 iframe 沙箱」**，重构了沙箱内核。
「空白同域 iframe 沙箱」的三个关键词（详细原理见 iframe JS 沙箱）：
- 空白（blank）：iframe 指向一个空白的同域地址，当作纯净的「白纸 window」承载子应用 JS。
- 同域（same-origin）：iframe 与主应用同源，
window.parent/contentWindow直连、document可代理——这是通信与 WC 桥接的地基。 - 支持浏览器前进后退：v2.0 沙箱让子应用在 iframe 里的路由操作正确进入浏览器历史栈，配合路由同步，浏览器的前进/后退按钮能正确驱动子应用路由——这是 v1 时代 iframe 与浏览器历史割裂的老痛点，v2.0 正面解决。
二、连发 4 版：2026-06 复活时间线
v2.0 不是发一版就停，而是一个月内连发 4 版密集迭代，是「复活」而非「昙花」的信号：
| 时间 | 版本 | 关键内容 |
|---|---|---|
| 2021~2023 | v1.0.0 → v1.0.29 | v1 线，iframe+WC 路线成型，此后长期沉寂 |
| 2026-06 初 | v2.0.0 | 全新空白同域 iframe 沙箱，支持浏览器前进后退 |
| 2026-06-03 | v2.0.1 | v2.0 沙箱问题修复迭代 |
| 2026-06-04 | v2.0.2 | 持续修复 |
| 2026-06-15 | v2.1.0 | 内联事件处理器子应用作用域执行、修异步 CSS 重复插入、修 destroy 竞态内存泄漏、新增 refreshApp |
v2.1.0（2026-06-15） 是复活后第一个 minor，四条变更含金量高：
- 内联事件处理器在子应用作用域执行：修正了 HTML 内联
onclick等在沙箱作用域的执行归属。 - 修复异步加载 CSS 重复插入：异步样式表不再重复注入。
- 修复子应用刷新
destroy竞态导致的内存泄漏：直击 iframe 路线最敏感的内存问题。 - 新增
refreshAppAPI：支持子应用全量重建刷新（对应重建模式的编程式触发）。
这几条修复看似琐碎，方向却很明确——都在补 iframe 路线最敏感的短板（内存泄漏、样式重复、作用域归属），是「认真维护」而非「刷个版本号」的信号。把 v2 相比 v1 的可感知变化列出来：
| 能力 | v1 线 | v2（2026-06 起） |
|---|---|---|
| iframe 沙箱内核 | 旧同域 iframe 沙箱 | 全新空白同域 iframe 沙箱 |
| 浏览器前进/后退 | 支持不完善 | 正确驱动子应用路由 |
| 子应用刷新内存 | destroy 竞态易泄漏 | v2.1.0 修复竞态泄漏 |
| 编程式全量刷新 | 无专用 API | refreshApp（v2.1.0 新增） |
| 维护活跃度 | 长期沉寂 | 月内连发 4 版 |
为什么这次复活值得关注：2026 年的微前端格局里，qiankun 3.0 三年 rc 难产、2.x 又接不了 Vite，「要强隔离又要 Vite 友好」一度是块空位。wujie 的 iframe 路线天然同时满足这两点，v2.0 复活恰好填补了这个位置——它不与 qiankun 抢「存量 webpack 开箱」的盘，而是卡住「Vite 时代 + 复杂子应用 + 强隔离」这个增量场景。这也是本叶把 wujie 单列一叶、而非并入 qiankun 讲的原因：它代表一条与 Proxy 软沙箱正交的技术路线。
三、选型定位：wujie 的甜区
把 wujie 放进 2026 微前端选型全景（全景见微前端基础·2026 选型），它的定位非常清晰——三个「最」：
- 隔离最强：iframe 物理隔离，子应用有独立的原生
window/history/location，不像 Proxy 软沙箱「防意外不防恶意」。 - Vite/ESM 最友好：ESM 交 iframe 里的浏览器原生执行，零改造接 Vite 子应用——这正是 qiankun 2.x 的最大痛点。
- 保活预加载秒开最顺：原生
alive保活 +preloadApp预加载/预执行，切换秒切、首进秒开。
对应的甜区场景：子应用复杂（大型 SPA、强样式/强全局副作用，需要强隔离兜底）+ 技术栈是 Vite + 追求切换/首屏体验。反过来，轻量子应用、极致省内存、单页嵌很多个小应用的场景，iframe 的内存开销就不划算，此时 qiankun/micro-app 的软沙箱更轻。
四、与 micro-app 的对比
wujie 和 micro-app（前向引用叶，京东出品）是 2026 两个「Vite 友好、组件化用法」的热门方案，常被放一起比。二者路线同中有异：
| 维度 | wujie | micro-app |
|---|---|---|
| 用法 | 组件 <WujieVue> / <wujie> 自定义元素 | 自定义元素 <micro-app name url>（类 Web Components） |
| 默认 JS 沙箱 | iframe 物理沙箱（最强、最重） | with/Proxy 软沙箱（更轻；也提供 iframe 模式） |
| DOM 容器 | <wujie> WebComponent + shadowRoot | 自定义元素（默认 scopedcss，可选 Shadow DOM） |
| 隔离强度 | 最强（物理） | 较强（软沙箱为主，iframe 模式可升级） |
| 内存开销 | 每应用一 iframe，较高 | 软沙箱模式较低 |
| 保活 | 原生 alive | 支持 keep-alive |
一句话区分：都主打「像用组件一样用子应用 + Vite 友好」，但 wujie 默认把隔离拉满（iframe 物理沙箱、代价是内存），micro-app 默认更轻（软沙箱、代价是隔离弱一档）。micro-app 的具体实现、沙箱模式、<micro-app> 用法属于它自己的叶（本站前向引用，待产出），本页不展开。
五、局限：iframe 路线的代价
wujie 的强隔离不是白来的，选型时要正视这些结构性代价：
- 内存与启动开销：每个子应用（尤其保活/预执行的）常驻一个 iframe + WebComponent + 其 JS 运行时，同屏多子应用内存占用高（见 保活与预加载·内存代价）。
- 同域约束：沙箱是同域 iframe，子应用直接操作
location（window.location.href = ...）可能替换掉 iframe 导致「跨域 frame 访问被拦」，须改用window.$wujie.location；Vite 子应用尤其要注意。 - 弹窗与 Shadow DOM：DOM 在
shadowRoot里，Popper 弹窗定位、@font-face字体需按常见问题处理（见 WC 渲染）。 - 第三方全局变量：脚本在 iframe 闭包里执行，库的全局声明可能不挂到 window，需
window.xxx = ...显式挂载或用插件替换。 - 降级体验：老浏览器
degrade回退到 iframe 直接渲染，弹窗无法覆盖全屏（见 iframe 沙箱·降级）。
六、选型决策：何时用 wujie、何时别用
把上面的「甜区」与「局限」合成一张可直接对照的决策表——wujie 不是万能钥匙，是「用内存换隔离与体验」的特化选择：
| 你的情况 | 倾向 | 原因 |
|---|---|---|
| 子应用是 Vite/ESM 技术栈 | ✅ wujie | ESM 交 iframe 浏览器原生执行，零改造；qiankun 2.x 接不了 |
| 子应用复杂、强全局副作用，要强隔离兜底 | ✅ wujie | iframe 物理隔离最强，防子应用互相污染 |
| 高频往返、要状态不丢 / 秒切 | ✅ wujie | 原生 alive 保活 + 预加载秒开 |
| 需要同屏并存多个子应用 | ✅ wujie | 组件化、天然多实例，无需注册 |
| 单页要嵌很多个轻量小应用 | ⚠️ 慎选 | 每应用一 iframe，内存开销叠加 |
| 存量 webpack 项目、要开箱即用 | ➡️ qiankun | 生态成熟、软沙箱省内存 |
| 要更轻的软沙箱 + 组件化用法 | ➡️ micro-app | with/Proxy 软沙箱，内存更省 |
| 要极致控制、自建底座 | ➡️ single-spa | 只做编排，隔离/加载自理 |
一条实践准则：先问技术栈（Vite → wujie 天然友好）、再问隔离需求（子应用越复杂、越需要强隔离越偏 wujie）、最后算内存账（并存子应用越多、越轻，iframe 开销越不划算）。选型全景（六框架横向对比）见微前端基础·2026 选型全景。
小结
wujie 在 2021~2023 迭代到 v1.0.29 后长期沉寂，2026-06 以 v2.0「全新空白同域 iframe 沙箱」复活、月内连发 4 版（v2.0.0/0.1/0.2/2.1.0），核心补上了「支持浏览器前进后退」，v2.1.0 还修了 destroy 竞态内存泄漏、新增 refreshApp。它的定位是隔离最强 + Vite 原生友好 + 保活预加载秒开，甜区是「复杂子应用 + 强隔离 + Vite」；与 micro-app 同走组件化 Vite 友好路线，但 wujie 默认把隔离拉满（iframe 物理沙箱、代价是内存）。局限也都源于 iframe 路线：内存/启动开销、同域约束、弹窗 Shadow DOM 逃逸。要把全部 API、模式、通信一表查全，见参考。