微前端JS沙箱实现全解析

本文深入剖析了HTML微前端中JS沙箱的实现本质，明确指出iframe（特别是同域about:blank iframe）是HTML层面唯一真正可靠、引擎级隔离的JS沙箱方案——它提供独立的window、document、history、location和事件循环，能彻底阻断子应用对主应用的全局污染和副作用；而所有纯JS方案（如Proxy代理、快照沙箱）均无法阻止eval、Function构造器等逃逸手段，本质上只是运行时劫持而非真实隔离；文章还详解了安全注入脚本的正确姿势（document.write而非eval）、通信规范（仅限postMessage）及高频踩坑点（跨域src误用、localStorage共享、CSS泄漏等），直击微前端落地中最易被忽视却至关重要的安全与稳定性命门。

直接用 iframe 是目前 HTML 层面唯一能实现真正 JS 沙箱隔离的方案，其他纯 JS 实现（如 Proxy、快照）都不算“HTML 做的”，而是运行时劫持，且无法阻止子应用直接修改 window 或触发原生副作用。

为什么只有 iframe 算 HTML 层沙箱

浏览器对 iframe 的隔离是引擎级的：它拥有独立的 window、document、history、location，甚至独立的事件循环和 JS 执行上下文。只要 src="about:blank" 且同域，就能通过 iframe.contentWindow 安全拿到一个干净、隔离、可编程的全局对象。这不是模拟，是真实副本。

其他方案都绕不开一个问题：代码最终还是在主页面的 JS 引擎里跑，哪怕用 Proxy 包一层 window，子应用仍能通过 eval、Function 构造器、with、Symbol.unscopables 等方式逃逸；快照沙箱更是在主 window 上直接改，靠“还原”来假装隔离——根本不是隔离。

• iframe 是唯一能让 window.addEventListener('click', ...) 不影响主站事件监听的方案
• 只有 iframe 能让 history.pushState 触发子应用路由但不污染主应用 history stack（需配合 joint session history）
• 跨域 iframe 可进一步用 sandbox="allow-scripts allow-same-origin" 控制能力，但同域 about:blank 更轻量、无网络请求、无 CSP 阻断风险

iframe.contentWindow 怎么安全注入子应用 JS

关键不是“怎么注入”，而是“注入后怎么不让它污染主环境”。正确做法是：不把子应用脚本 eval 到主页面，而是写入 iframe 的 document 并执行。

示例流程：

const iframe = document.createElement('iframe');
iframe.src = 'about:blank';
document.body.appendChild(iframe);

const win = iframe.contentWindow;
const doc = win.document;

// 写入子应用 HTML 结构（含 script 标签）
doc.open();
doc.write(`
  
  
    <base href="%24%7BsubAppBase%7D"><div id="root"></div>
      <script src="%24%7BsubAppEntry%7D"><\/script>
    
  
`);
doc.close();
</script>

• 必须确保 subAppEntry 是同域资源，否则跨域会触发 CORS 或拒绝执行
• 很重要，否则子应用内相对路径的 fetch、图片、样式等会 404
• 不要用 win.eval() 或 win.execScript()，那等于把代码拉回主上下文执行，沙箱失效
• 若需通信，只走 postMessage + message 事件，避免任何直接引用（如 win.xxx）

常见踩坑：你以为隔离了，其实没隔离

很多团队用 iframe 却仍然出现变量冲突或样式泄漏，问题不在沙箱本身，而在使用方式。

• 误用 iframe.src 指向真实子应用 URL（如 https://sub.example.com），导致跨域，contentWindow 无法访问，只能退化为黑盒 iframe，无法控制生命周期和通信
• 在主页面 document.head 中动态插入子应用的