先证明需要，再谈方案

四条路线的取舍【iframe】隔离 100%，体验 60% JS / CSS / 全局变量全隔离，靠浏览器原生 问题：弹窗无法覆盖父页面、路由和前进后退割裂、 父子通信只能 postMessage、首屏多一次文档加载 适合：嵌入第三方不可信页面、老系统改造预算极低 【qiankun】隔离 80%，体验 85% 基于 single-spa，JS 用 Proxy 沙箱，CSS 用 scoped 或 shadow DOM 子应用按约定的生命周期导出 bootstrap / mount / unmount 问题：沙箱不是真隔离（有些全局逃逸）、样式隔离靠约定 适合：大多数中大型企业的后台系统 【wujie】隔离 95%，体验 85% 每个子应用一个隐藏 iframe 跑 JS（拿到原生隔离） 渲染到主应用的 shadow DOM 里（布局和弹窗正常） 问题：社区和生态比 qiankun 小 适合：既想要强隔离又不想牺牲体验 【Module Federation】不做隔离，只做共享 webpack 5 / Vite 的运行时模块共享 优点：依赖能共享一份，不重复打包 缺点：要求所有子应用用同一套构建工具和框架版本 适合：同一技术栈、想共享依赖的场景

三种沙箱的对比【快照沙箱】snapshot 激活时给 window 拍快照，退出时 diff 出改了什么、还原 优点：实现简单 缺点：只能有一个子应用在跑；window 属性多时 diff 很慢 用于：qiankun 的单实例模式 【Proxy 沙箱】proxy 每个子应用一个 Proxy 假 window 优点：支持多实例同时运行，不用遍历 window 缺点：逃逸情况多（document.body 直接改、事件监听、定时器） 用于：qiankun 的多实例模式、大部分自研方案 【iframe 沙箱】 子应用在 iframe 里执行，window 是真的、原生隔离 优点：隔离彻底，不用维护 Proxy 的边界 缺点：iframe 和主文档通信有成本 用于：wujie

四代方案与它们的破绽【一、命名约定】BEM 加应用前缀 .app-order__title { } 破绽：靠人守，第三方库和 UI 框架的全局样式照样污染 【二、运行时改选择器】qiankun 的 experimentalStyleIsolation .title { } → div[data-qiankun="order"] .title { } 优点：不用改子应用代码 破绽：@keyframes、@font-face、:root 变量不会被改写； 动态插入的 style 标签要监听；!important 仍然穿透 【三、shadow DOM】真隔离 shadowRoot 里的样式出不去，外面的进不来 破绽：弹窗渲染到 body 时会脱离 shadow， 第三方库大量依赖 document 查询会失效 【四、iframe】最彻底 style 完全独立，连 CSS 变量都不继承

三种共享方式的取舍【externals】主应用提供，子应用不打包 // webpack externals: { react: 'React', 'react-dom': 'ReactDOM' } // 子应用里 import React from 'react' 会被替换成 window.React 优点：立竿见影，体积直接减掉 缺点：版本强绑，子应用不能用不同的 React 版本 【Module Federation】运行时按需共享 shared: { react: { singleton: true, requiredVersion: '^18' } } 优点：可以指定版本范围，singleton 保证全局一份 缺点：要求都用 MF 体系构建 【各带一份】 优点：子应用完全自治，升级互不影响 代价：体积翻倍（React + ReactDOM 约 130KB gzip） 什么时候可接受：子应用是懒加载的，首屏不受影响

先评估这三个问题1. 有几个团队？发布节奏真的冲突吗？ 一个团队 → 不需要。用 monorepo 解决构建和复用问题 两个团队但节奏一致 → 大概率也不需要 2. 公共组件多不多？ 多 → 微前端会让每个应用各维护一份，反而更痛 替代：内部组件库 + 版本管理 3. 首屏性能是硬指标吗？ 是 → 微前端会多一层运行时和重复依赖 替代：单个应用做路由级分包 仍然需要的情况： 多个团队、独立发布是刚需 技术栈暂时无法统一（收购来的系统、老系统） 单仓构建时间已经影响研发效率