proxy无法实现完全隔离，因其不能拦截eval、function构造函数等js语言级逃逸路径；唯一可靠方式是iframe，proxy沙箱仅用于防误操作和工程约束。

Proxy 本身不能构建“完全隔离”的沙箱环境——它只能实现运行时的访问控制，无法拦截 eval、Function 构造函数、with 语句、Symbol.unscopables 等 JS 语言级逃逸路径。所谓“完全隔离”，在 HTML 环境中唯一可靠的方式是 iframe；Proxy 沙箱的本质是“防误操作 + 工程约束”，不是安全边界。

为什么 Proxy 无法真正隔离 window

子应用代码仍在主页面 JS 引擎中执行，所有逃逸手段都直通原始 window：

• eval('window.location.href') 绕过代理，直接读取真实 location
• new Function('return window')() 创建新函数作用域，返回原始全局对象
• with (window) { console.log(location); } 触发作用域链查找，跳过 Proxy trap
• 动态插入 <script></script> 或调用 document.write，脚本直接运行在宿主上下文

Proxy 沙箱的实际定位与正确用法

它不是用来替代 iframe 的“强隔离”，而是作为轻量层，解决常见污染问题：属性覆盖、全局变量泄漏、副作用扩散。主流框架（如 qiankun）把它和 iframe 结合使用：

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 用 iframe.contentWindow 构造干净的 fakeWindow，天然继承原生 API（setTimeout、fetch 等）
• 对这个 fakeWindow 创建独立 Proxy 实例，每个子应用一个，绝不复用
• get trap 控制读取来源：优先 fakeWindow → 白名单属性（如 console）→ 原始 window
• set trap 仅写入 fakeWindow，不触碰原始 window，避免污染

关键 trap 设计要点

只靠 get/set 不够，必须补全其他拦截点才能防止绕过：

• has(target, p)：控制 p in proxyWindow 的返回值，隐藏原始 window 上的非白名单属性
• ownKeys(target)：决定 Object.keys(proxyWindow) 和 for...in 能看到哪些键，通常只返回 fakeWindow 自有属性 + 白名单
• deleteProperty：拦截 delete proxyWindow.xxx，避免误删影响主应用
• 对 addEventListener、setTimeout 等需单独 wrap，记录监听器以便卸载时清除，防止内存泄漏

真正安全的落地组合

不要在 Proxy 上追求“完全隔离”，而要分层设计：

• 强隔离层：同域 iframe（src="about:blank"），提供独立 window、document、history、事件循环
• 运行时防护层：基于 iframe.contentWindow 的 Proxy，做细粒度读写控制、路由重写（location.href → 子应用基座路径）、副作用记录
• 通信层：用 CustomEvent 绑定到中央 EventTarget，不依赖 window 或 document，卸载即清理
• 工程兜底：禁用 eval、限制 Function 使用、约定子应用不操作 document.head 等，靠规范+CI 检查保障

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！