与相邻方案的关系

基于微前端 2026 生态 · 核于 2026-07

速查

• vs iframe 经典结论（Fowler）：隔离最强——样式与全局变量天然互不干扰、拼页容易；但体验割裂——路由/历史/深链接更复杂、响应式更难，跨应用集成不灵活
• wujie 新视角：把 iframe 降级为纯 JS 沙箱——JS 在 iframe 里执行（原生隔离），DOM 却渲染在主文档的 Web Component 容器里 → 保留隔离、绕开割裂；2026-06 v2.0 携全新 iframe 沙箱复活
• 「iframe = 落后」在 2026 已不成立：iframe 作为隔离原语被重新启用，作为渲染容器才是体验割裂的根源
• vs monorepo：仓库形态与部署单元是两个正交维度——Vercel 官方：mono/polyrepo 下微前端行为完全一致，「每个应用都是独立项目、独立部署，无论代码放在哪」
• monorepo 解决代码共享与原子重构，微前端解决部署与运行时解耦——只要前者时 monorepo 就够（Vercel 反判据），两者也常叠用（monorepo + 微前端是 2026 常见形态）
• vs BFF（Fowler）：每个微前端配一个同团队拥有的 BFF（backend for frontend）——「其唯一目的是服务这一个前端的需求」；指导原则：别让团队等其他团队给它做东西
• 鉴权例外：token 由容器统一获取注入（横切关注点），BFF 只消费不发起登录
• vs 模块化单体：构建时组合（npm 包集成）的归宿就是模块化单体——好架构，但不是微前端，收益模型完全不同（无独立部署）
• 共享组件库与微前端正交：design system 照建，但 Fowler 纪律——共享库只放 UI 逻辑，「领域逻辑进共享库会在应用间制造高度耦合」
• 判别公式：微前端 = 独立部署 ∧ 运行时组合——只有代码拆分是模块化，只有运行时加载是懒加载，两条都满足才是微前端

一、vs iframe：老对手与新变奏

1.1 经典结论

iframe 是最早也最省事的「运行时组合」，Fowler 对它的双面评价至今是标准答案：

iframe 让「从独立子页面拼出一个页面」变得容易，在样式与全局变量互不干扰方面提供了不错的隔离度。……但它让路由、历史与深链接更复杂，也给页面完全响应式带来额外挑战。

维度	裸 iframe	微前端框架（qiankun 系）
JS/样式隔离	浏览器原生，最强	沙箱/作用域样式模拟，有逃逸面
URL 与深链	内外两套 history，深链要自行同步	容器统一路由（见路由分发与容器模式）
布局与弹窗	遮罩/下拉难以跨出边界，响应式难	同一文档流，天然自由
通信	postMessage 序列化边界	props/事件/共享内存均可
加载成本	每帧一套完整浏览上下文	可共享依赖与运行时

结论一句话：iframe 用隔离换融合——对信任度低、融合要求低的场景（第三方页面、遗留系统「先挂上再说」）它依旧是性价比之王。标签细节见 HTML 章 · iframe 嵌入，sandbox 属性与点击劫持防护见浏览器安全章。

1.2 wujie 变奏：iframe 当沙箱，不当容器

体验割裂的根源并非 iframe 本身，而是把渲染也关进了 iframe。腾讯 wujie 的路线把 iframe 拆开用：JS 放进 iframe 执行——拿到浏览器原生的全局隔离，不必像 qiankun 那样自研 Proxy 沙箱去模拟 window；DOM 渲染到主文档的 Web Component 容器——布局、弹窗、响应式回到同一文档流，样式由 Shadow DOM 隔离。隔离与融合的经典互斥，被「执行与渲染分离」拆掉了一角。

这条路线在 2026-06 用 v2.0 的全新 iframe 沙箱完成复活（一个月连发 4 版，见 2026 选型全景）。工程后果：「用 iframe 就是技术落后」的等式作废——2026 年的正确问法是「iframe 用在哪一层」：当渲染容器（割裂照旧），还是当 JS 沙箱（wujie 路线），还是只当安全边界（第三方内容）。原理细拆见 wujie 叶与核心机制叶。

1.3 什么时候仍该直接用裸 iframe

微前端框架不是 iframe 的全面上位替代，三种场景下裸 iframe 依旧是正解：

• 低信任第三方内容：外部供应商页面、客服/支付挂件——你要的本来就是安全边界而非融合，配合 sandbox 属性按白名单授权（见浏览器安全章）；
• 合规硬隔离：审计要求「代码互不可见、故障互不传染」时，浏览器原生边界比任何自研沙箱都好向审计方解释；
• 一次性挂载遗留系统：老系统只求「能被打开」、不求体验融合——iframe 五分钟接完，微前端框架改造反而要动遗留代码。

判断句式：融合要求越低、信任度越低，裸 iframe 越占优；反过来才轮到微前端框架登场。

二、vs monorepo：正交的两个维度

最常见的概念混淆：「上微前端 = 拆仓库」。Vercel 文档把这件事说死了：

无论你把应用放在一个仓库（monorepo）还是分散在多个仓库（polyrepo），微前端的工作方式完全相同。……每个应用都是自己的 Vercel 项目、独立部署，无论它的代码放在哪里。

也就是说，仓库形态（mono/poly）与部署单元（单体/微）是两个正交维度，四个象限都有名有姓：

	单体部署	微前端（独立部署）
monorepo	最常见默认形态	2026 工程主流之一：同仓多项目，共享 lint/TS 配置，配置自动发现
polyrepo	传统多站点	Fowler 文的默认想象：每团队一仓一管道；配置需显式分发

分工也随之清楚：monorepo 解决代码共享与原子重构（一次 PR 改所有调用方、共享工具链、增量构建），微前端解决部署与运行时解耦（各上各的线）。由此推出两条实践结论：

• 你的痛点若只是代码共享/规范统一——monorepo 就是终点，这正是 Vercel 反判据里「先考虑 Turborepo」的含义（见适用判据与反判据）；
• 决定上微前端后，仓库形态按团队边界与权限敏感度选：跨 BU、权限硬隔离选 polyrepo，其余默认 monorepo——既拿原子重构的好处，又不牺牲独立部署。

三、vs BFF：纵切一路切到后端

微前端把团队按业务纵切到了 UI 层，Fowler 追问了一句：数据从哪来？答案是纵切不应停在浏览器——理想的团队「从视觉代码一路拥有到 API 开发、数据库与基础设施」。落到架构上就是 BFF（Backend For Frontend）模式：

每个前端应用都有一个对应的后端，其唯一目的是服务这一个前端的需求。

BFF 可以自含全部业务逻辑，也可以只做下游微服务的聚合层。判断要不要给每个微前端配 BFF 的指导原则，Fowler 给得非常朴素：「构建某个微前端的团队，不应该等待其他团队为他们构建东西。」——如果一个通用 API 层能让所有团队自助，不配也行；如果每次新需求都要跨团队提接口排期，那就是需要 BFF 的信号。

┌── 团队 A ──────────┐   ┌── 团队 B ──────────┐
│ 微前端 A            │   │ 微前端 B            │
│   ↓                │   │   ↓                │
│ BFF A（仅服务 A）    │   │ BFF B（仅服务 B）    │
└───┬────────────────┘   └───┬────────────────┘
    └────→ 下游共享微服务 / 领域服务 ←────┘

边界上有一个不动点：登录鉴权不下放。用户只登录一次，token 由容器获取并注入各微前端（见路由分发与容器模式），BFF 只负责校验与消费。工程后果：BFF 让纵切闭环、自治成真，但服务数量随之翻倍——这笔运维账要计入 Fowler Downside③（治理复杂度）一起核算。

四、vs 模块化单体与共享组件库

模块化单体：把前端按业务拆成 npm 包、workspace 包，构建时合成一个产物——这就是组合模式三分法里的构建时组合。它有清晰边界、有代码复用，是好架构；它不是微前端，因为不满足独立部署——改任何一块都要整体重发。用错标签的代价是成本模型错配：按微前端立项（多管道、多仓库治理），按单体交付（锁步发布），两头的亏一起吃。

共享组件库 / design system 与微前端正交——拆了应用不等于放弃视觉一致性。但 Fowler 给共享库立了两条纪律：

• 只放 UI 逻辑，不放领域逻辑：「领域逻辑放进共享库，会在应用间制造高度耦合」——改一条业务规则要全体升级依赖，锁步经由 npm 复活；
• 先各写各的，再收割（harvest）：让重复的模式先在各代码库里自然浮现，成熟后再抽进共享库，避免过早抽象；治理上「人人可贡献 + 专职守护者（custodian）把关质量与一致性」。

最后收拢成一条判别公式，一切「这算不算微前端」的争论到此为止：

微前端 = 独立部署 ∧ 运行时组合。 只有代码拆分 → 模块化单体；只有运行时加载 → 懒加载/代码分割；两条同时成立才是微前端。

五、判别速查表

方案	解决什么	部署单元	与微前端的关系
iframe	页面级强隔离嵌入	各自独立	微前端的组合手段之一；wujie 将其重用为 JS 沙箱
monorepo	代码共享、原子重构	不限定	正交维度，常与微前端叠用；也是官方反判据里的前置替代方案
BFF	前端专属后端、纵切闭环	每 BFF 独立	微前端在服务端的自然延伸；鉴权仍归容器
模块化单体	代码边界与复用	单一	构建时组合的归宿；好架构但非微前端
组件库 / design system	视觉与交互一致性	随宿主构建	正交；只放 UI 逻辑，领域逻辑禁入
懒加载 / 代码分割	首屏性能	单一	只有运行时加载、没有独立部署，不是微前端

小结

四场边界战各有结论：iframe 是隔离最强、融合最差的组合原语——但 wujie 证明把它只用作 JS 沙箱就能留隔离去割裂，「iframe 落后论」在 2026 作废；monorepo 与微前端是正交维度（Vercel：mono/polyrepo 行为一致），前者管代码共享、后者管部署解耦；BFF 让纵切从 UI 一路闭环到后端，每微前端配同团队 BFF、鉴权留容器；模块化单体是构建时组合的归宿，与微前端隔着「独立部署 ∧ 运行时组合」这条判别公式。概念边界全部画完，最后一个问题最实际：2026 年的今天，具体该在谁家之间选——2026 选型全景。