子应用互相污染微前端沙箱在 CSS 与 JS 双层的隔离治理一、三个子应用上了线全局变量互相覆盖微前端的隔离难题某中后台聚合了三个子应用订单、库存、报表。上线第二周订单子应用挂了 window.orderConfig报表子应用也挂了同名的全局变量后挂的覆盖前挂的订单页配置错乱。更麻烦的是样式订单的 .card 选择器泄漏到报表页面报表的按钮圆角被改成订单的样式。三个团队互相甩锅排查一周才定位到是隔离缺失。这事我见过太多团队栽进去——把多个子应用塞进一个壳却没做运行时隔离。微前端的核心难题不是加载而是隔离。多个子应用共享同一个浏览器全局环境JS 层的 window 对象、原型链、定时器、事件监听CSS 层的全局选择器、第三方库样式。没有隔离子应用之间就是共享一个全局命名空间互相踩踏。JS 层的典型冲突全局变量覆盖、原型污染某子应用给 Array.prototype 加了方法影响所有子应用、定时器泄漏子应用卸载后 setTimeout 仍在跑、事件监听泄漏卸载后仍监听 window 事件。CSS 层的典型冲突全局选择器碰撞多个子应用都用 .card 或 .btn、第三方组件库全局样式泄漏如 antd 的 .ant-btn、动态插入的 style 标签未隔离。这些冲突在开发环境往往不暴露到了聚合后才爆发。二、JS 快照沙箱与 CSS 隔离方案双层隔离的底层机制JS 隔离有三套主流方案。第一套是快照沙箱。子应用挂载前遍历 window 拍快照子应用卸载后把 window 恢复到快照状态。兼容性好不支持 Proxy 的旧浏览器也能用。但性能差每次挂载卸载都要遍历 window且子应用运行期间仍会互相污染。第二套是 Proxy 沙箱。每个子应用分配一个 fake window用 Proxy 代理。子应用访问 window 时实际访问的是自己的 fake window。写操作只落在 fake window 上互不污染。卸载时只需丢弃 fake window无需恢复。qiankun 默认采用这套方案是单实例场景下的最优解。第三套是 iframe 隔离。子应用跑在 iframe 里天然物理隔离window、原型链、样式全部独立。最彻底但通信成本高弹窗、路由、全局样式需额外处理。适合对隔离要求极高的场景。CSS 隔离也有三套方案。第一套是 Shadow DOM。子应用根节点用 attachShadow 创建影子根样式天然隔离外部进不来内部出不去。最彻底但第三方库如 antd 的 Modal 挂到 body会失效需 portal 方案将弹窗挂到子应用影子根内。第二套是 Scoped CSS运行时样式改写。子应用加载后运行时给所有选择器加属性前缀如 .card 变成 .card[data-apporder]。需处理动态插入的 style 标签与内联样式。qiankun 默认采用这套方案。第三套是 CSS Modules构建时生成唯一类名。子应用在构建期为每个类名生成唯一 hash天然不冲突。需子应用配合改造对历史项目侵入性大。样式冲突的运行时治理是最后一道防线。第三方组件库的全局样式、动态插入的 style 标签需 MutationObserver 监听并改写避免泄漏到其他子应用。综上子应用从加载、激活到卸载全程处在沙箱管控内全局变量与样式不外泄生命周期事件由宿主统一调度。把这条时序守住多应用共存时才不会互相污染。三、生产级轻量 Proxy 沙箱与样式隔离实现下面给出一个可复用的轻量沙箱封装。它包含 Proxy 沙箱激活与卸载、样式属性前缀改写。interface SandboxOptions { appName: string; rootEl: HTMLElement; } class ProxySandbox { // 每个子应用独立的 fake window写操作只落这里 private fakeWindow: Recordstring, unknown {}; private proxy: Window; private active false; private appName: string; private rootEl: HTMLElement; private styleObserver?: MutationObserver; constructor(opts: SandboxOptions) { this.appName opts.appName; this.rootEl opts.rootEl; const fakeWindow this.fakeWindow; // Proxy 代理 window读优先取 fakeWindow写只落 fakeWindow this.proxy new Proxy(window as unknown as Window, { get(target, key: string) { if (key in fakeWindow) return fakeWindow[key]; const val (target as any)[key]; // 原生函数需绑定到真实 window否则 alert 等会报非法调用 return typeof val function ? val.bind(target) : val; }, set(_target, key: string, value) { // 写操作不污染真实 window只落 fakeWindow fakeWindow[key] value; return true; }, has(_target, key: string) { return key in fakeWindow; }, }); } // 激活沙箱劫持子应用执行环境并启动样式监听 activate() { if (this.active) return; this.active true; this.patchStyleScope(); } // 卸载沙箱丢弃 fakeWindow停止样式监听 deactivate() { this.active false; this.fakeWindow {}; this.styleObserver?.disconnect(); } // 在沙箱环境内执行子应用代码 exec(code: string) { // 用 with 把 proxy 注入为子应用的全局对象 const fn new Function(window, with(window){${code}}); fn.call(this.proxy, this.proxy); } // 样式隔离给子应用内所有选择器加属性前缀 private patchStyleScope() { const prefix [data-app${this.appName}]; // 根节点打属性标记作为前缀锚点 this.rootEl.setAttribute(data-app, this.appName); // 监听子应用内动态插入的 style 标签实时改写 this.styleObserver new MutationObserver((mutations) { for (const m of mutations) { for (const node of m.addedNodes) { if (node instanceof HTMLStyleElement) { this.rewriteStyle(node, prefix); } } } }); this.styleObserver.observe(this.rootEl, { childList: true, subtree: true }); // 改写已存在的 style 标签 this.rootEl .querySelectorAll(style) .forEach((s) this.rewriteStyle(s, prefix)); } // 把 .card 改成 [data-apporder] .card隔离作用域 private rewriteStyle(styleEl: HTMLStyleElement, prefix: string) { try { const css styleEl.textContent ?? ; // 简化版改写匹配选择器并加前缀生产环境需用 postcss 完整解析 const rewritten css.replace(/([^{}])\{/g, (_match, selectors: string) { const scoped selectors .split(,) .map((s: string) { const trimmed s.trim(); // 跳过 规则与 keyframes避免误改导致动画失效 if (trimmed.startsWith()) return trimmed; return ${prefix} ${trimmed}; }) .join(, ); return ${scoped} {; }); styleEl.textContent rewritten; } catch (err) { // 样式改写失败不阻断渲染记录后跳过 console.error([ProxySandbox:${this.appName}] 样式改写失败, err); } } } export { ProxySandbox };关键点在于三处。其一Proxy 拦截 window 的读写写操作只落 fakeWindow互不污染。其二函数属性绑定到真实 window避免 alert、setTimeout 等原生 API 报非法调用。其三MutationObserver 监听动态插入的 style 标签并改写选择器保证运行时插入的样式也被隔离。某中后台接入后三个子应用的全局变量与样式冲突全部消失互相改 bug 不再踩对方。四、沙箱隔离的代价性能开销、第三方库兼容与适用边界沙箱隔离并非无损。Proxy 沙箱有性能开销。每次 window 访问都走 Proxy 拦截有微小延迟。高频访问场景如每帧读 window.innerWidth需注意。某动画子应用曾因频繁读 window 属性Proxy 拦截开销累计每帧 2 毫秒。后来把 window 属性读到局部变量缓存问题缓解。第三方库兼容是最头疼的问题。antd、Element UI 等组件库的弹窗、Toast 默认挂到 document.body在 Shadow DOM 方案下会逃出影子根样式失效。需用 portal 方案把弹窗挂到子应用根节点内或改造组件库的 getContainer 配置。qiankun 也遇到同样问题社区有大量 issue。样式改写有成本且可能漏网。运行时改写选择器需完整 CSS 解析器正则替换会漏掉复杂选择器与 规则。动态插入的内联样式style 属性无法用前缀改写需单独处理。生产环境建议用 postcss 做完整解析而非正则。iframe 隔离通信成本高。postMessage 序列化开销大复杂交互延迟明显。路由、全局样式、字体都需额外同步。适合对隔离要求极高但交互简单的场景。适用边界中后台聚合、多团队协作的大型前端门户收益最高。单团队单应用的场景不需要微前端引入沙箱是过度设计徒增复杂度与性能开销。五、总结微前端的隔离治理核心是 JS 与 CSS 双层隔离配合运行时样式监听。落地建议第一JS 隔离优先用 Proxy 沙箱每个子应用分配 fake window写操作不污染真实 window。第二旧浏览器降级到快照沙箱兼容性优先。第三对隔离要求极高的场景用 iframe物理隔离最彻底但要接受通信成本。第四CSS 隔离用 Shadow DOM 最彻底但需改造第三方库弹窗挂载点。第五Scoped CSS 用运行时改写选择器需配合 MutationObserver 监听动态插入的样式。第六CSS Modules 在构建期生成唯一类名需子应用配合改造。第七单团队单应用不引入微前端避免过度设计。这条路在多团队聚合的中后台场景下能跑通回报是值得的。