微前端中的 JavaScript 沙箱机制：快照沙箱与 Proxy 沙箱实现

微前端架构的核心挑战之一，是如何让多个独立开发、独立部署的子应用在同一页面中和谐共存。其中最关键的问题便是 JavaScript 全局变量污染——子应用在运行时可能会修改 window 上的属性，若不加隔离，切换应用后残留的状态会直接影响其他子应用的正常运行。沙箱机制正是为解决这一问题而生的。

为什么需要 JavaScript 沙箱

在微前端场景中，每个子应用本质上都是一段可以独立运行的代码。这些代码通常假设自己独占浏览器环境，会直接访问和修改 window、document 等全局对象。当多个子应用同时或交替运行时，就会出现以下问题：

• 全局变量冲突：子应用 A 在 window 上挂载了 appConfig，子应用 B 也挂载了同名变量，后者会覆盖前者。
• 状态残留：子应用 A 卸载后，其设置的 setTimeout、事件监听器、全局变量仍然存在，影响后续子应用。
• 样式污染：虽然本文聚焦 JavaScript，但全局状态污染往往与样式污染相伴而生。

沙箱的目标就是为每个子应用创造一个“看起来像独立 window”的运行环境，使其对全局对象的修改被限制在自身范围内，卸载时能够干净地还原。

快照沙箱的实现原理

快照沙箱（Snapshot Sandbox）的核心思想非常直观：在子应用激活前，记录当前 window 上的所有属性作为“快照”；子应用运行期间，允许它直接修改真实的 window；当子应用卸载时，将 window 恢复到快照记录的状态。

基本实现

class SnapshotSandbox {
  constructor() {
    this.modifiedProps = {}; // 记录子应用修改过的属性
    this.snapshot = {};      // 保存激活前的 window 快照
    this.active = false;
  }

  // 激活沙箱
  active() {
    this.snapshot = {};
    // 1. 记录当前 window 上的所有属性
    for (const key in window) {
      this.snapshot[key] = window[key];
    }
    // 2. 恢复上一次该子应用运行时的修改
    for (const key in this.modifiedProps) {
      window[key] = this.modifiedProps[key];
    }
    this.active = true;
  }

  // 卸载沙箱
  inactive() {
    this.modifiedProps = {};
    // 1. 对比当前 window 与快照，记录差异并还原
    for (const key in window) {
      if (window[key] !== this.snapshot[key]) {
        this.modifiedProps[key] = window[key];
        window[key] = this.snapshot[key];
      }
    }
    // 2. 处理快照中存在但当前 window 中已被删除的属性
    for (const key in this.snapshot) {
      if (!(key in window)) {
        window[key] = this.snapshot[key];
      }
    }
    this.active = false;
  }
}

工作流程

1. 激活阶段：遍历 window，将所有属性存入 snapshot。如果该子应用之前运行过，则将其上次修改的属性恢复到 window 上。
2. 运行阶段：子应用直接操作真实的 window，没有任何拦截。
3. 卸载阶段：再次遍历 window，找出与快照不同的属性，记录到 modifiedProps 中，然后将 window 还原为快照状态。

优缺点分析

优点：

• 实现简单，兼容性极好，可以支持到 IE 浏览器。
• 不需要 Proxy，不依赖现代浏览器特性。

缺点：

• 无法支持多个子应用同时运行：因为所有子应用共享同一个真实 window，快照沙箱只能串行工作。
• 性能开销随 window 属性数量增长：每次激活和卸载都需要遍历整个 window 对象。
• 无法拦截动态操作：对于 window.a.b = 1 这类深层修改，快照对比只能检测到 window.a 的变化，无法精确还原。

Proxy 沙箱的实现原理

Proxy 沙箱利用 ES6 的 Proxy 对象，为每个子应用创建一个“假 window”。子应用对全局变量的读写操作都会被 Proxy 拦截，从而在不污染真实 window 的前提下运行。

基本实现

class ProxySandbox {
  constructor() {
    const fakeWindow = {};
    const rawWindow = window;

    this.proxy = new Proxy(fakeWindow, {
      get(target, key) {
        // 优先从子应用自己的 fakeWindow 中读取
        if (key in target) {
          return target[key];
        }
        // 否则从真实 window 读取
        const value = rawWindow[key];
        // 处理函数类型的属性，确保 this 指向正确
        if (typeof value === 'function' && !value.prototype) {
          return value.bind(rawWindow);
        }
        return value;
      },
      set(target, key, value) {
        // 所有写操作都落到 fakeWindow 上，不污染真实 window
        target[key] = value;
        return true;
      },
      has(target, key) {
        return key in target || key in rawWindow;
      }
    });
  }
}

关键设计点

1. 读操作的代理

当子应用访问 window.setTimeout 时，Proxy 的 get 拦截器会先检查 fakeWindow 中是否存在该属性。如果不存在，则从真实 window 中读取。这样既保证了子应用能访问浏览器原生 API，又不会将原生 API 复制到 fakeWindow 中造成冗余。

2. 写操作的隔离

所有对 window 的赋值操作都被拦截并写入 fakeWindow。这意味着子应用 A 设置 window.appName = 'A' 时，真实 window 上不会出现 appName，子应用 B 也不会读到这个值。

3. 函数 this 指向的处理

直接从真实 window 上取到的函数（如 setTimeout），如果直接返回，调用时 this 可能指向 fakeWindow 而非 window，导致部分 API 报错。因此需要对函数进行 bind(rawWindow) 处理。

4. 支持多实例共存

由于每个子应用拥有独立的 fakeWindow 和 Proxy 实例，多个子应用可以同时运行而互不干扰。这是 Proxy 沙箱相比快照沙箱最大的优势。

局限性

• 兼容性：Proxy 是 ES6 特性，无法兼容 IE11 及以下浏览器。不过随着现代浏览器普及，这已不是主要问题。
• 变量声明提升：使用 var 声明的全局变量会直接挂载到真实 window 上，Proxy 无法拦截。需要配合 with 语句或代码转换来规避。
• document 等对象：Proxy 沙箱通常只代理 window，对于 document、location 等对象的隔离需要额外处理。

两种沙箱的对比与选型

在实际微前端框架中，qiankun 采用了组合策略：如果浏览器支持 Proxy，则使用 Proxy 沙箱；否则降级为快照沙箱。这种渐进增强的思路值得借鉴。

总结

JavaScript 沙箱是微前端实现隔离的关键技术。快照沙箱通过“记录-还原”的方式实现简单隔离，适合兼容性要求高的场景；Proxy 沙箱通过拦截读写操作实现更彻底的隔离，支持多应用同时运行，是现代微前端框架的主流选择。理解两者的实现原理和适用边界，有助于在实际项目中做出合理的技术选型，也为进一步探索更复杂的沙箱方案（如基于 iframe 的硬隔离）打下基础。

未经允许不得转载：任鹏个人博客 » 微前端中的 JavaScript 沙箱机制：快照沙箱与 Proxy 沙箱实现