illegalCreed

中文

English

中文

English

Appearance

与应用级方案的选型 ​

基于 Module Federation 2.0（v2.6 2026-06） · 核于 2026-07

速查 ​

  • 本质分野：MF 是模块级 + 无沙箱（共享组件/依赖，同 window）；qiankun/wujie 是应用级 + 带沙箱（挂载整应用，隔离全局与样式）。选型第一问就是你要共享「模块」还是要隔离「应用」。
  • 「无沙箱」的准确含义：联邦模块与宿主共享同一个 window、全局、DOM、CSS 作用域——MF 不做 JS 沙箱、不做样式隔离，也不打算做（这是定位，不是缺功能）。
  • 无沙箱的红利：无 Proxy/iframe 开销、能直接共享 React 实例与 context / 同一个 store、通信就是普通函数调用——「像同一个应用里的两个模块」。
  • 无沙箱的代价（自治成本）：全局变量互撞、CSS 泄漏、window 污染没有兜底，全靠团队自律（约定命名前缀、CSS Modules/scoped、禁改全局）——规模越大、团队越杂，自律越难维持。
  • 沙箱的红利与代价正相反：qiankun/wujie 用沙箱换来「乱写也不互相污染」，代价是重（Proxy/iframe）、难共享运行时（两份 React 实例）、以及沙箱本身的坑（弹窗逃逸、@keyframes 不改写等，见核心机制）。
  • 它们常常叠加而非二选一：成熟模式是用 single-spa/qiankun 做应用级编排（谁在什么路由挂载）+ 用 MF 做模块级依赖共享（大家共用一份 React/设计系统）——各取所长。
  • 混用红线：叠加时，同一依赖只能有一个权威解析源——不要同一个 React 既走 import maps 又走 MF shared，否则双份实例、singleton 名存实亡（见依赖共享三路线）。
  • 选 MF 的信号：同技术栈、多团队要细粒度共享组件/逻辑/大依赖、团队能自律、要运行时版本协商与治理工具。
  • 选应用级（qiankun/wujie）的信号：强隔离刚需——老系统林立、CSS 混乱、每块技术栈不同、团队互不信任、要「整应用挂载」而非「共享模块」。
  • wujie/micro-app 的位置：iframe/WebComponent 沙箱、对 Vite/ESM 友好——「要隔离又要 Vite」时优先它们；qiankun 2.x 不接 ESM。
  • 2026 坐标（InfoQ）：MF 与 single-spa、import maps、Piral 同台；MF 的差异点是「运行时版本协商 + 内建错误边界」，规模化治理更强。
  • 全景选型见微前端基础 · 2026 选型全景；配置细节见构建工具章 · webpack 深入。

一、两个物种：模块级 vs 应用级 ​

先把最容易混的一点钉死：MF 和 qiankun 不是同一类工具的两个牌子，而是两个物种。差异不在「哪个更好」，在它们解决的粒度不同：

Module Federationqiankun / wujie（应用级）
复用单位模块（组件/函数/store）整个子应用（带路由的 SPA）
核心动作跨应用 import() 一个模块mount(container) 挂载整应用
隔离无沙箱，同 window/DOM/CSSJS 沙箱 + 样式隔离
依赖共享运行时 semver 协商（真共用实例）各自带 / import maps（通常不共实例）
通信同 realm，直接函数调用/共享内存跨沙箱：props / 全局状态 / 事件
典型诉求多团队共享代码、去重大依赖老系统渐进拆分、强隔离共存

一句话记牢：MF 让两个应用「像同一应用里的两个模块」，qiankun 让两个应用「像同一页里的两个隔离租户」。这条差异是下面一切选型判断的根。

二、「无沙箱」到底意味着什么 ​

MF「无沙箱」常被误读成「不成熟」，其实是刻意的定位选择。准确含义：联邦模块执行在宿主的同一个 realm 里，共享同一个 window、同一份全局对象、同一棵 DOM、同一个 CSS 作用域。MF 不提供 JS 沙箱，也不提供样式隔离——而且不打算提供。

这一个事实同时是红利与代价的来源：

红利（为什么无沙箱是优点）：

  • 能真正共享运行时：两个应用用同一个 React 实例——所以 hooks、context、Suspense 跨应用可用；这正是联邦概念里「模块级复用」得以成立的前提。沙箱方案做不到这点（隔离的 window 里是两份 React）。
  • 零隔离开销：没有 Proxy 代理 window、没有 iframe——加载快、内存省。
  • 通信零成本：同 realm，import 来的函数直接调，import 来的 store 直接订阅，不需要序列化/事件桥。

代价（自治成本）：

  • 全局互撞无兜底：两个团队都往 window.__CONFIG__ 写、都定义了全局 dayjs——没有沙箱拦着，直接互相覆盖。
  • CSS 会泄漏：A 的 .btn { color: red } 会作用到 B 的按钮——没有样式隔离，全靠 CSS Modules / scoped / BEM 前缀等约定自保。
  • 副作用不回收：子应用卸载时，它加的全局监听、定时器、<style> 不会像 qiankun 那样被沙箱记账清理——得自己管。

结论：MF 把「不互相污染」的责任从框架下放给了团队纪律。这在同一组织、能统一约定的前提下是划算的（换来轻量与真共享）；在团队互不信任、技术栈各异、遗留 CSS 混乱的场景下则很危险——那正是沙箱方案的主场。

三、沙箱方案的对称取舍 ​

反过来看 qiankun/wujie 的沙箱，取舍正好镜像：

  • 红利：「乱写也不互相污染」——子应用可以随便用全局、随便写 CSS，沙箱兜底。这让「把一堆历史包袱各异的老系统塞进一个壳」成为可能。
  • 代价：重（proxySandbox 代理 window，或 wujie 的 iframe）、难共享运行时（隔离的 window 里 React 是两份，跨应用共享 context 很别扭）、以及沙箱自身的坑（qiankun 的 Shadow DOM 弹窗逃逸、experimentalStyleIsolation 不改写 @keyframes——通论见核心机制 · CSS 隔离）。

一张表看穿对称性：

无沙箱（MF）带沙箱（qiankun/wujie）
隔离靠团队自律靠框架兜底
共享运行时（一份 React）天然可以别扭/做不到
开销轻重（Proxy/iframe）
适合团队同组织、能统一约定互不信任、技术栈杂
适合系统新系统、共享驱动老系统、隔离驱动

四、叠加模式：编排 + 共享各取所长 ​

真实的大型微前端常常不是二选一，而是叠加——因为「应用级编排」和「模块级共享」本就正交（见联邦概念第五节）：

text
┌─────────────────────────────────────────────┐
│  single-spa / qiankun  ← 应用级编排层         │
│  （谁在什么路由 mount/unmount、沙箱隔离）      │
│                                               │
│      每个子应用内部 ↓ 又用                     │
│  Module Federation    ← 模块级共享层           │
│  （大家共用一份 React、共享设计系统组件）       │
└─────────────────────────────────────────────┘

single-spa 官方也把「single-spa 编排 + MF 共享依赖」列为成熟可行模式。叠加时唯一红线来自依赖共享三路线：同一依赖只能有一个权威解析源——别让同一个 React 既走 import maps 又走 MF shared，两套解析互不知晓，结果是双份实例、singleton 名存实亡。工程混用没问题，但依赖名单必须二选一划界。

五、选型决策树 ​

把上面的判断收敛成一棵树：

text
你的首要诉求是「隔离整应用」还是「共享模块」？
│
├─ 隔离整应用（老系统林立 / CSS 混乱 / 技术栈各异 / 团队互不信任）
│   └─ 用应用级方案（带沙箱）
│       ├─ 存量 webpack + 要开箱即用 ──────► qiankun
│       └─ 新项目 / Vite / 要更强隔离 ─────► wujie / micro-app（ESM 友好）
│
├─ 共享模块（同技术栈 / 多团队共用组件与大依赖 / 团队能自律）
│   └─ 用 Module Federation
│       ├─ webpack/Rspack 主力 ───────────► MF 2.0（Rspack 内置）
│       ├─ Vite 主力 ───────────────────► @module-federation/vite（官方）
│       └─ Angular / 想贴浏览器标准 ──────► Native Federation
│
└─ 两个都要（既要编排整应用、又要跨应用共享依赖）
    └─ 叠加：single-spa/qiankun 编排 + MF 共享
        └─ 红线：同一依赖只走一套解析（import maps 或 MF shared，二选一）

补两条 2026 的坐标（InfoQ 观察）：MF 与 single-spa、import maps、Piral 同处一个竞争面；MF 的差异化壁垒是「运行时版本协商 + 内建错误边界集成」，在规模化治理上更强，代价是心智比「纯 import maps」重。完整全景与各方案横评见微前端基础 · 2026 选型全景。

小结 ​

MF 与 qiankun 系的选型，归根到底是**「模块级共享 + 无沙箱」对「应用级组合 + 带沙箱」**的取舍。「无沙箱」不是缺陷而是定位：它换来轻量与「真共享一份运行时」的能力，代价是把隔离责任下放给团队自律——适合同组织、能统一约定的共享驱动场景；沙箱方案则用「框架兜底不互相污染」适配老系统林立、强隔离驱动的场景。二者常叠加（编排 + 共享各取所长），唯一红线是同一依赖别混两套解析。一句话收尾：要隔离「应用」选带沙箱的 qiankun/wujie，要共享「模块」选无沙箱的 MF，都要就叠加。 全部结论的速查汇总见参考。