微前端沙箱隔离核心是防止子应用间全局污染，主要方案包括：1. 用Proxy代理window实现运行时隔离，支持状态回滚但不兼容IE；2. 快照机制在加载前后保存恢复window状态，兼容好但性能开销大；3. Webpack模块联邦在构建时隔离依赖，适合多团队协作；4. iframe提供强隔离但通信复杂，Shadow DOM可辅助组件隔离。实际多采用Proxy为主、快照为辅的混合策略，结合规范与测试保障安全。
微前端架构中，JavaScript 沙箱隔离的核心目标是防止不同子应用之间的全局环境互相污染。由于多个子应用可能同时运行在同一个页面上，若不加以隔离，它们对 window、document 或全局变量的修改可能引发冲突。解决这一问题需要从执行环境和作用域控制入手。
1. 动态代理 window 实现沙箱隔离
通过 ES6 的 Proxy 对全局对象 window 进行代理，可以拦截子应用对全局属性的读写操作，实现运行时隔离。
- 创建沙箱时，用 Proxy 包裹 window，记录子应用修改的属性
- 子应用运行结束后，可选择恢复原始状态（快照机制）或丢弃变更
- 优点：轻量、灵活，能精确控制访问行为
- 限制：IE 不支持 Proxy，需降级方案
2. 快照机制（Snapshot）回滚状态
在子应用加载前保存 window 状态，卸载时还原变更。这是一种兼容性较好的沙箱实现方式。
- 进入子应用时，遍历并记录 window 上所有可枚举属性
- 退出时，对比差异，删除新增属性，恢复被覆盖的值
- 适用于不支持 Proxy 的环境
- 缺点：性能开销大，无法捕获函数内部引用的全局变量变化
3. 构建时模块联邦与作用域隔离
利用 Webpack Module Federation，让子应用在构建层面就隔离依赖。
立即学习“Java免费学习笔记（深入）”；
4. Shadow DOM + iframe 辅助隔离（按需使用）
对于强隔离需求，可借助 iframe 创建完全独立的 JavaScript 执行环境。
- iframe 天然具备沙箱能力，window 和 DOM 完全隔离
- 通信需通过 postMessage，增加复杂度
- 样式和路由管理更麻烦，一般用于嵌入第三方系统
- Shadow DOM 可辅助封装组件级隔离，但不解决 JS 全局污染
基本上就这些主流方案。实际项目中，通常以 Proxy 沙箱为主，快照为辅，配合良好的规范约束子应用行为。关键是根据浏览器兼容性、性能要求和团队结构做权衡。沙箱不是万能的，开发阶段的约定和测试同样重要。
