如何利用“单例代理”模式实现在微前端环境下对全局 window 对象的安全沙箱化-js教程-PHP中文网

单例代理模式不适用于微前端沙箱化window，因其无法隔离子应用、导致状态污染和内存泄漏；必须采用多实例沙箱（如proxy+fakewindow或iframe）实现真正隔离。

如何利用“单例代理”模式实现在微前端环境下对全局 window 对象的安全沙箱化

单例代理模式在微前端中不能直接用于安全沙箱化 window，它只适合做状态协调或生命周期管理；真要隔离 JS 执行环境，必须用多实例沙箱（如 Proxy + 独立上下文）或 iframe。强行用单例代理 window，会导致子应用互相污染、激活/失活时状态错乱、setTimeout 回调丢失等严重问题。

为什么单例代理 window 在微前端中不适用

单例代理意味着所有子应用共享同一个代理对象，背后仍是同一个 window 原始引用。这带来几个硬伤：

多个子应用同时修改 window.foo = 1 和 window.foo = 2，后写入者覆盖前写入者，无隔离可言
子应用卸载时无法还原自己改过的属性（比如删掉 window.myLib），因为代理层没记录“谁改了什么”
addEventListener('popstate', ...) 这类绑定会累积，卸载后仍生效，造成内存泄漏和事件重复触发
像 fetch、XMLHttpRequest、Promise 等原生构造函数被代理后，无法拦截其内部对 window 的隐式访问（例如 Promise.resolve() 内部仍走原始全局）

QianKun 中的 single-spa 沙箱实际用的是多实例模式

QianKun 默认启用的 proxySandbox 是多实例代理：每个子应用加载时，都会创建一个独立的 Proxy 实例，包裹一个「干净的 fakeWindow」（非真实 window），所有读写都落在该实例上。关键点在于：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

fakeWindow 是基于 iframe.contentWindow 构造的（同域 about:blank），天然继承全部原生 API
Proxy 拦截 get/set/deleteProperty，但对 has、ownKeys 等也做了适配，防止 in 操作符绕过
激活时把 fakeWindow 上的变更同步到真实 window（仅限白名单属性，如 location、history）；失活时清空 fakeWindow，但保留共享对象引用（如 document、console）
不是所有属性都可代理：Symbol.unscopables、Function.prototype.toString 等需单独 patch，否则子应用可通过 eval 或 with 绕过

如果你非要手动实现一个轻量沙箱，别碰单例代理

可以基于 iframe 快速搭出可用沙箱，比 Proxy 更可靠，且兼容性更好：

const iframe = document.createElement('iframe', { src: 'about:blank' });
document.body.appendChild(iframe);
const sandboxGlobal = iframe.contentWindow;

// 把需要共享的对象挂到 sandboxGlobal 上
sandboxGlobal.document = document;
sandboxGlobal.location = location;
sandboxGlobal.console = console;

// 执行子应用代码（注意：需 eval 或 script 标签注入）
sandboxGlobal.eval(`console.log('running in sandbox');`);

注意几个坑：