在微前端架构中，多个子应用运行在同一浏览器环境下，JavaScript 的全局对象 window 被所有子应用共享。如果子应用 A 在 window 上定义了全局变量 `globalData`，而子应用 B 也定义了同名变量，后加载的应用可能会覆盖先前的值，导致运行时错误或难以追踪的数据污染。此外，事件监听、定时器、全局 CSS 等资源的冲突也频繁发生。要实现微前端应用的稳定运行，必须对每个子应用的 JS 执行环境进行隔离，让它们看起来像是在各自独立的沙箱中运行。本文将围绕两种常见的隔离方案展开：基于 Proxy 的代理沙箱和基于快照的恢复沙箱。
Proxy 沙箱：用代理拦截全局访问
Proxy 是 ES6 引入的元编程特性，可以创建一个对象的代理，拦截对该对象的各种操作。在微前端场景中，我们可以为每个子应用创建一个 Proxy 代理，将全局对象 window 包装起来，所有对 window 的读写操作都经过这个代理。代理内部维护一个属于该子应用的“伪全局对象”存储，当子应用代码尝试读取 `window.someProp` 时，代理先检查自己的存储中是否存在该属性，若存在则返回存储中的值，否则返回真实 window 上的值；当子应用代码尝试写入 `window.someProp = value` 时，代理将值写入自己的存储中，而不是直接修改真实的 window 对象。这样一来，子应用之间的全局变量读写互不干扰。
以下是一个简化版的 Proxy 沙箱实现，展示了核心逻辑：
class ProxySandbox {
constructor(name) {
this.name = name;
// 存储子应用自身的全局变量
this.proxyState = {};
// 创建一个代理，拦截对 window 的访问
this.proxy = new Proxy(window, {
get(target, key) {
// 如果 key 在子应用自己的存储中，直接返回
if (key in this.proxyState) {
return this.proxyState[key];
}
// 否则返回真实 window 上的值
return target[key];
},
set(target, key, value) {
// 所有写入都保存到子应用自己的存储中，不修改真实 window
this.proxyState[key] = value;
return true;
},
has(target, key) {
return key in this.proxyState || key in target;
}
});
}
// 激活沙箱：将代理对象作为全局环境注入
active() {
window.proxy = this.proxy;
// 实际微前端框架会用更复杂的方式注入，这里简化
}
// 销毁沙箱：清除子应用的所有全局变量
inactive() {
this.proxyState = {};
}
}
上述代码中，`ProxySandbox` 为每个子应用实例化一个独立的 `proxyState` 对象，用来保存该子应用对全局变量的写入。当子应用代码执行 `window.foo = 'bar'` 时，实际被代理拦截，`foo` 被存入 `proxyState` 中，真实的 `window.foo` 并未被修改。当子应用需要读取 `window.foo` 时，代理优先从 `proxyState` 返回。这样就实现了变量隔离。更完善的实现还会处理 `deleteProperty`、`defineProperty` 等操作，以及对 `document`、`history` 等对象的特殊处理。
Proxy 沙箱的优势在于灵活性高，可以精确控制全局对象的读写行为，且隔离粒度细，多个子应用可以同时运行而互不影响。由于 Proxy 是现代浏览器原生支持的特性，性能开销也相对较低。但它的缺点是需要浏览器支持 Proxy（IE 不支持），且对于某些通过非标准方式访问全局变量的代码（如直接使用 `eval` 或 `Function` 构造器）可能绕过代理。此外，对于事件监听、定时器等副作用，Proxy 沙箱本身不负责清理，需要框架额外处理。
快照沙箱：激活时记录，卸载时恢复
快照沙箱的思路更为直接：在子应用挂载（激活）之前，遍历并记录 window 对象上所有可枚举属性的键和值，生成一份全局状态快照；在子应用卸载（失活）时，再次遍历 window 对象，将当前状态与之前保存的快照进行对比，找出差异并将 window 恢复到快照时的状态。这种方式确保了子应用运行期间对全局对象的修改在卸载后被完全擦除，从而不影响其他子应用或主应用。
一个基本的快照沙箱实现如下：
class SnapshotSandbox {
constructor() {
this.windowSnapshot = {};
this.modifiedProps = new Set();
}
// 激活：保存当前 window 快照
active() {
// 记录现有属性
for (const key in window) {
this.windowSnapshot[key] = window[key];
}
}
// 失活：恢复 window 到快照状态
inactive() {
// 遍历当前 window 所有属性，与快照对比
for (const key in window) {
if (!(key in this.windowSnapshot)) {
// 快照中不存在的属性是子应用新增的，删除
delete window[key];
this.modifiedProps.add(key);
} else if (window[key] !== this.windowSnapshot[key]) {
// 快照中存在但值被修改了，恢复原值
window[key] = this.windowSnapshot[key];
this.modifiedProps.add(key);
}
}
// 如果快照中有但当前window没有的属性，需要恢复（可能被删除）
for (const key in this.windowSnapshot) {
if (!(key in window)) {
window[key] = this.windowSnapshot[key];
}
}
}
}
该实现使用 `for...in` 遍历 window 的可枚举属性，但这种遍历并不完整，因为有些属性是不可枚举的，且无法获取 `Symbol` 键。实际生产中（如 qiankun 框架）会使用 `Object.getOwnPropertyNames(window)` 和 `Object.getOwnPropertySymbols(window)` 来获取所有自有属性，确保快照的完整性。快照沙箱的优点是实现逻辑简单直观，不依赖 Proxy，兼容性更好。缺点是一次只能激活一个子应用（因为快照是全局的，同时激活多个会互相覆盖快照），并且每次激活和失活都需要遍历全局对象，当 window 上属性很多时性能开销较大。此外，快照沙箱无法隔离多个同时运行的子应用，只能用于单实例场景。
Vue 3 应用中沙箱集成的实践要点
Vue 3 本身基于 Proxy 实现响应式系统，因此运行 Vue 3 的环境必然支持 Proxy，这意味着在选择 Proxy 沙箱时无需担心浏览器兼容性问题。但在微前端框架中集成 Vue 3 子应用时，仍有一些细节需要关注。例如，Vue 3 在全局对象上会挂载一些内部标识（如 `__VUE__`、`__VUE_DEVTOOLS_GLOBAL_HOOK__` 等），这些标识如果被沙箱拦截或恢复，可能导致 Vue 应用初始化失败或 Devtools 异常。在 Proxy 沙箱中，这些内部属性通常应该被共享而不是隔离，可以通过白名单机制让某些属性的读写直接操作真实 window；在快照沙箱中，则应在快照保存和恢复时避开这些关键属性。
以 qiankun 框架为例，其默认提供了基于 Proxy 的沙箱（称为 ProxySandbox）和基于快照的沙箱（称为 SnapshotSandbox），开发者可以通过配置选择。在 Vue 3 子应用中，推荐开启 `{ sandbox: { strictStyleIsolation: true, experimentalStyleIsolation: true } }` 来加强样式隔离，同时 JS 隔离默认使用 Proxy 沙箱。如果子应用需要兼容旧版浏览器（不支持 Proxy），可降级使用快照沙箱，但要注意此时多个子应用不能同时激活，否则快照会互相干扰。
一个典型场景是：主应用使用 Vue 3 开发，子应用也是 Vue 3 或者 React。当两个 Vue 3 子应用同时挂载时，如果使用 Proxy 沙箱，它们各自的响应式系统可以正常工作，因为每个子应用的 `window` 代理存储是独立的，Vue 3 内部对全局 `Proxy` 的引用仍然共享，但不会造成变量冲突。不过需要注意，Vue 3 的响应式依赖 `window` 对象吗？实际上 Vue 3 的响应式只依赖 `Proxy` 和 `Reflect`，并不直接访问 `window` 上的用户变量，因此 Proxy 沙箱不会影响 Vue 3 内部运行。真正需要隔离的是子应用代码中自行定义的全局变量，以及第三方库可能写入 window 的全局配置。
此外，无论是哪种沙箱，都需要管理子应用的生命周期，确保在卸载时清理事件监听、定时器等副作用。Vue 3 的 `onUnmounted` 等生命周期钩子并不能覆盖所有全局副作用（如手动添加的 window 事件监听），因此微前端框架通常会提供额外的卸载钩子，或者在沙箱的 `inactive` 阶段统一清理。在开发 Vue 3 子应用时，应当避免直接操作 `window` 和 `document` 上的全局事件，或者使用框架提供的统一注册接口。
两种沙箱的对比与选型建议
Proxy 沙箱与快照沙箱并非互斥方案，它们适用于不同的微前端架构需求。如果需要同时激活多个子应用，且每个子应用需要完全隔离的全局环境，Proxy 沙箱是更合适的选择，因为它为每个子应用维护独立的存储空间。如果应用场景是单实例模式（同一时间只激活一个子应用），且对兼容性有较高要求，快照沙箱则更为简单可靠。从性能角度看，Proxy 沙箱在运行期间的读写操作会有额外的代理开销，但通常可以忽略不计；快照沙箱的激活和失活操作开销较大，但在子应用运行期间没有额外开销。
在实际项目中，可以结合两种沙箱的优势：例如使用 Proxy 沙箱作为默认方案，当检测到浏览器不支持 Proxy 时自动降级到快照沙箱，并限制同时激活的子应用数量为 1。无论选择哪种方案，都必须重视全局副作用的清理，包括定时器、全局事件监听、MutationObserver、WebSocket 连接等，否则即使全局变量被隔离，内存泄漏和意外回调依然会导致问题。
总结来说，JS 隔离是微前端架构稳定性的基石。理解 Proxy 沙箱和快照沙箱的工作原理，能够帮助开发者在 Vue 3 项目中做出更合理的架构决策，避免多应用共存时的全局污染问题。建议读者结合实际项目复杂度、浏览器支持矩阵和性能要求，选择或定制属于自己的隔离方案。