esmodule在多实例沙箱中无法直接复用模块缓存，需通过动态构建独立加载上下文实现隔离；核心是绕过全局modulemap，采用blob url重写、shadowrealm预编译或iframe自定义loader等方案，并管控全局对象、import.meta、循环依赖等关键环节。
ESModule 在多实例沙箱中无法直接复用同一模块缓存，必须打破默认的 ModuleMap 共享机制，通过动态构建独立模块加载上下文来实现安全隔离。
核心问题：ESM 的模块缓存是全局共享的
浏览器和 Node.js 中，import() 或静态 import 加载的模块会按规范 URL（或解析后的绝对路径）缓存在 ModuleMap 中。即使在不同沙箱（如多个 VM.Context、ShadowRealm 或自建 iframe）中执行，只要模块地址相同，就会命中同一个已编译、已执行的模块实例 —— 这导致状态污染、副作用交叉、导出对象被共用，完全违背沙箱隔离目标。
可行方案：动态重写 + 独立加载上下文
要实现真正隔离，需绕过原生模块缓存，为每个沙箱构造专属的模块加载链路。主流做法有三类：
-
运行时源码重写 + Blob URL 动态加载：获取模块源码后，将所有
import语句改写为带唯一命名空间前缀或沙箱 ID 的路径（如import './utils.js'→import './utils.js?sid=abc123'），再用Blob创建唯一 URL，调用import()。因 URL 不同，模块被视作全新资源，触发独立解析与执行。 -
ShadowRealm + 动态 import() 配合预编译模块字节码（实验性）：在
ShadowRealm内部调用import()，配合服务端提前将模块转为无依赖的 IIFE 或 ESM 字符串（剥离顶层import，内联或替换为沙箱内受控加载器）。注意：当前ShadowRealm不支持直接import外部 URL，需配合eval或importScripts（仅 Worker）等降级方式。 -
iframe 沙箱 + module type script + 自定义 loader：创建带
sandbox属性的iframe，注入一个轻量 loader（如基于SystemJS改造），重写System.register或拦截fetch，为每个模块请求注入沙箱标识头或 query 参数，服务端据此返回带命名空间包装的模块代码（例如导出对象挂载到window.__sandbox_abc123下），避免全局污染。
关键细节：确保真正隔离的四个要点
只改 URL 不够，还需控制以下环节：
-
禁止跨沙箱共享模块对象：不通过
postMessage或SharedArrayBuffer传递模块导出值；若需通信，只传序列化数据，由接收方沙箱内重新导入对应模块处理。 -
覆盖全局标识符（如
globalThis、window）：在沙箱执行前冻结或代理全局对象，防止模块通过globalThis.fetch等访问宿主环境能力 —— 应提供沙箱专属的fetch、setTimeout等受限封装。 -
禁用
import.meta.url和import.meta.resolve：这些 API 可泄露模块路径或触发非预期加载，应在沙箱内将其置为undefined或抛出错误。 -
处理循环依赖与动态
import()嵌套：每个沙箱需维护自己的模块解析图（ModuleRecord树），不能复用宿主的Loader内部状态；建议使用简易 ES Module 解析器（如es-module-lexer）预分析依赖，再逐层注入重写后的 URL。
实用建议：生产可用的最小可行路径
对大多数前端微前端或插件场景，推荐组合使用：
- 用
esbuild或rollup将第三方模块打包为iife，导出函数接受沙箱上下文作为参数； - 沙箱运行时用
new Function或eval（在严格 CSP 下启用'unsafe-eval'）执行该函数，传入隔离后的globalThis和受限 API； - 对仍需 ESM 语法的模块（如现代组件库），采用
Blob + URL.createObjectURL+ query 参数强制去重，并在服务端做简单路径映射（/mod/utils.js?sid=abc → /sandbox/abc/utils.js），确保物理文件也隔离。
不复杂但容易忽略：模块隔离的本质不是“不让它跑”，而是“让它在自己的世界里完整跑一遍”——从解析、链接、求值到导出，每一步都需绑定到沙箱生命周期内。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
