模块模式无沙箱能力，真正隔离需Proxy沙箱等运行时机制：构建fakeWindow代理globalThis，拦截set/get操作并限制敏感对象访问，叠加seccomp-bpf、SELinux等系统级防护，UTS/UniModule中避免全局污染。

模块模式本身不提供沙箱能力，所谓“利用模块模式的沙箱特性”是一种常见误解。真正能锁死核心宿主变量的，是运行时隔离机制（如 Proxy 沙箱、WebAssembly 边缘沙箱、eBPF 容器沙箱），而非 ES Module 的静态作用域。模块只是封装了变量可见性，无法阻止子应用通过 window.xxx = ... 或 eval 动态篡改全局状态。

用 Proxy 沙箱替代模块幻想

第三方 SDK 往往直接读写 window、document、localStorage 等宿主对象。模块无法拦截这些行为，必须靠代理层：

• 构建 fakeWindow 对象，所有子应用的 globalThis 都指向它，而非真实 window
• 用 Proxy 的 set trap 拦截所有赋值，对关键字段（如 APP_ENV、__MOUNTED__）做只读或审计处理
• 对敏感对象（如 location、history）在 fakeWindow 上只暴露 getter，setter 中抛出错误
• 禁止子应用访问原生 window：Proxy 的 get trap 对 window.window、window.self 返回 fakeWindow 自身

在 SDK 初始化阶段注入隔离上下文

很多 SDK 要求传入 context 或调用 window.init()。此时需提前锁定入口：

• 在加载 SDK 前，将 fakeWindow 注入其执行环境（例如通过 script.src + eval 包裹，或动态创建 iframe 并重写其 contentWindow）
• 若 SDK 支持配置对象，把 globalThis 替换为受控的代理对象，而非默认 window
• 对 SDK 内部可能使用的 Function('return this')() 等绕过方式，在 Proxy 的 get 中统一拦截并返回受限对象

配合底层沙箱加固宿主变量不可写性

仅靠 JS 层 Proxy 不足以防止恶意代码逃逸。需叠加系统/容器级防护：

• 在 Docker AI 沙箱中，用 seccomp-bpf 白名单禁用 mprotect、mmap 等内存重映射系统调用，防止运行时 patch 全局对象
• Android 环境下，SELinux 策略应标记 SDK 所在进程为 untrusted_app，禁止其 write 到 system_file 或其他应用 data 目录
• Chrome 扩展中，启用 "sandbox": true 清单字段，让 SDK 运行在无 DOM、无 window 的纯 JS 沙箱页中，彻底切断宿主变量访问路径

用 UTS 或 UniModule 封装 SDK 时主动放弃全局污染

在 uni-app 或 HarmonyOS 开发中，不要让 SDK 直接挂载到 window：

• 在 UTS 插件中，SDK 初始化逻辑全部收口到 ArkTS 类内部，对外只暴露 async 方法，不导出任何全局变量
• UniModule 的 WeightModule.java 中，所有状态保存在私有 static 字段或 WeakMap 中，避免使用 public static 全局引用
• 初始化完成后，显式调用 delete window.WeightSDK（在 fakeWindow 上），或用 Object.defineProperty(fakeWindow, 'WeightSDK', { writable: false }) 锁定