模块沙箱本质是运行时环境隔离而非版本胶水，通过独立执行上下文实现“分治”，适用于微前端、多版本库共存等场景，但不解决编译期冲突；需配合状态禁用、样式隔离、路径白名单等配置，并实测验证隔离效果。
模块沙箱不是万能的“版本胶水”，而是通过运行时环境隔离，让不同版本的库在逻辑上互不感知。关键不在于“共存”，而在于“分治”——每个模块拥有独立的执行上下文，避免全局污染。
明确沙箱适用边界
沙箱解决的是运行时隔离问题，不是编译期或链接期冲突。它对以下场景有效：
- JavaScript 中多个微应用同时使用不同版本的 Lodash 或 Axios
- PowerShell 模块加载不同版本的 Newtonsoft.Json（需配合程序集加载上下文控制）
- qiankun 微前端中主应用与子应用使用不同 React 版本（v17 vs v18）
但无法解决：
- Go module 中 “multiple modules provide package” 编译错误（需用 replace 或调整依赖树）
- Java 类路径下两个同名 class 文件的加载冲突（JVM 不允许同一类被不同类加载器重复定义为同一类型）
- Python 中本地 json.py 覆盖标准库（这是路径优先级问题，应靠命名规范和 sys.path 控制）
选择匹配技术栈的沙箱机制
不同语言/框架提供的沙箱能力差异显著，需按实际环境选用：
-
qiankun（Web 前端）：启用
sandbox: { strictStyleIsolation: true }，自动创建 Proxy 包裹的 window、document 等全局对象，阻断跨微应用变量污染 -
PowerShell：无法直接沙箱化，但可通过
Import-Module -Force+Remove-Module手动清理，或改用 .NET 5+ 的AssemblyLoadContext实现轻量级隔离 - RobotStudio（Windows 桌面应用）：无原生沙箱，需人工实现路径隔离（如重定向 %APPDATA%\ABB\RobotStudio 到版本专属目录）+ 注册表键值虚拟化
- Python / Go / Java 后端服务：推荐进程级隔离（如 Docker 容器），而非模块级沙箱；模块沙箱在这些生态中缺乏稳定、通用的工程实践支撑
配置沙箱的关键动作
仅开启开关不够，必须配合配套约束才能真正生效：
- 禁用共享状态：关闭 localStorage、IndexedDB、BroadcastChannel 等跨沙箱通信通道（qiankun 默认隔离，但需确认未手动绕过）
- 样式强制隔离：启用
experimentalStyleIsolation防止 CSS 规则泄漏，尤其当不同版本 UI 组件存在同名 class 时 - 资源路径白名单：限制沙箱内脚本只能访问预设域名或本地静态资源，防止意外加载冲突版本的 CDN 库
- 日志与错误归因：为每个沙箱实例添加唯一标识前缀（如
[micro-app-A-v2.1]），便于定位异常来源
验证是否真正隔离
不能只看启动成功，要实测关键冲突点：
- 在沙箱 A 中执行
window.myLib = { version: '1.0' }，检查沙箱 B 中window.myLib是否仍为undefined - 分别在两个沙箱中引入不同版本 moment.js，调用
moment().format('YYYY')，确认输出格式一致且无报错（排除原型链污染） - 查看浏览器开发者工具的 Sources 面板，确认两个微应用的 JS 文件位于不同 iframe 或执行上下文，而非共用同一 globalThis
