闭包构建前端沙箱容器实现逻辑物理隔离

闭包本身并不能实现物理隔离，它提供的是逻辑作用域隔离——这恰恰是构建前端沙箱时最轻量、也最可控的起点。真正的“物理”级隔离，往往需要依赖 iframe 或 Web Worker 这类更底层的浏览器能力。但不可否认，闭包是构建一个可预测、可复位沙箱环境的关键底层机制。

闭包如何模拟独立执行上下文

Ja vaScript 的函数作用域天然就是一个封闭环境。这个特性被巧妙地利用了：当子应用的代码被包裹进一个立即执行函数，并且传入一个伪造的全局对象（比如 fakeWindow、fakeDocument）时，它就失去了直接访问真实宿主 window 的能力。此时，所有变量的读写操作，都被限制在了这个闭包形成的作用域链之内。

• 不修改原生对象：子应用里看似在操作 window.a = 1，实际上写入的是闭包内部传入的那个 fakeWindow 对象。
• 避免变量泄漏：闭包内部声明的变量（比如 const internalState = {}），外部环境是无法访问的。
• 支持按需注入：可以在闭包中只暴露指定的 API 给子应用，例如只提供 fetch 方法，而屏蔽掉 localStorage。

典型实现方式：函数包装 + 伪造全局对象

这种思路在微前端领域并不陌生。像 qiankun 的 LegacySandbox，或者更早的 ConsoleOS 方案，都采用了类似的策略。具体实现时，通常会在构建阶段通过 webpack 插件，自动为子应用的代码添加一层包装器：

(function(window, document, location) {
  // 子应用原始代码被注入此处
  console.log(window === self); // false，这里的 window 指向 fakeWindow
})(fakeWindow, fakeDocument, fakeLocation);

这里的 fakeWindow 可以是一个纯粹的空对象，也可以是一个预设了部分属性的对象。无论如何，子应用对它的任何操作，都不会污染到真实的全局环境。

闭包沙箱的局限与补强策略

当然，仅靠闭包是远远不够的。它有几个明显的短板：无法拦截子应用可能已经缓存了的全局引用（比如提前保存了 window.addEventListener）、无法阻止通过原型链进行的访问、也不具备在应用卸载后自动还原全局状态的能力。因此，在实际的工程实践中，闭包通常需要与其他技术组合使用：

• 搭配 Proxy：在 fakeWindow 外面套上一层 Proxy 袋里，可以动态拦截属性的访问和赋值操作，这很好地弥补了闭包方案静态性不足的缺点。
• 配合快照机制：在激活子应用前，先记录一份 window 关键属性的快照；当子应用卸载时，再根据快照恢复被修改过的属性。这对于处理像 history.pushState 这类调用尤其有效。
• 限制 with 语句：虽然 with 语句能动态扩展作用域，但它已被现代 Ja vaScript 规范所弃用，且存在明显的性能和安全隐患，在生产环境的沙箱中并不推荐使用。

为什么它仍是重要基础

与 iframe 那种重量级的隔离方式，或者 Web Worker 带来的线程通信开销相比，基于闭包的方案启动速度更快、调试更友好、兼容性也极佳（甚至能支持到 IE9+）。它并不追求绝对的安全，而是以最小的侵入代价，达成一种“开发阶段可信赖、运行阶段可兜底”的隔离效果。在微前端架构中，它常常是更复杂的 ProxySandbox 和 SnapshotSandbox 方案的前置准备环节。同时，它也是构建轻量级脚本执行沙箱（例如低代码平台中的动态表达式求值）时的首选范式。