微前端沙箱机制与iframe通信详解

---

一、微前端沙箱机制

沙箱（Sandbox） 是微前端中用于隔离子应用运行环境的核心机制，确保子应用的 JavaScript 执行、CSS 样式、DOM 操作 不会影响其他应用或基座。以下是常见的沙箱实现方式：

---

1. JavaScript 沙箱

• 目标：防止全局变量污染（如 window、document 被篡改）。
• 实现方案：
• Proxy 代理：
通过 Proxy 对象劫持子应用对全局变量的访问，限制其修改范围。

   // 伪代码：创建JS沙箱
    function createSandbox() {
   
    
    
      const fakeWindow = {
   
    
    };
      const proxy = new Proxy(fakeWindow, {
   
    
    
        get(target, key) {
   
    
    
          return target[key] || window[key]; // 优先从沙箱读取
        },
        set(target, key, value) {
   
    
    
          target[key] = value; // 修改仅作用于沙箱内部
          return true;
        }
      });
      return proxy;
    }

◦ **应用场景**：`qiankun`、`single-spa` 等框架使用此方式。
◦ **优点**：轻量级，性能较好。
◦ **缺点**：无法完全隔离 `DOM` API（如 `document.createElement`）。

• iframe 沙箱：
iframe 天然具有独立的 window 对象，可实现彻底隔离。
◦ 优点：完全隔离 JS 环境。
◦ 缺点：加载性能差，通信复杂，无法共享依赖（如 React）。

---

2. CSS 隔离

• 目标：避免样式冲突（如类名重复、全局样式污染）。
• 实现方案：
• Shadow DOM：
将子应用的 DOM 封装在 Shadow Root 中，外部样式无法渗透，内部样式不影响全局。
```html

<script>
  const container = document.getElementById('micro-app-container');
  const shadowRoot = container.attachShadow({ mode: 'open' });
  // 子应用的 DOM 挂载到 shadowRoot 下
</script>
```
◦ **优点**：原生支持，隔离彻底。
◦ **缺点**：部分 UI 库（如 Ant Design）可能不兼容。

• Scoped CSS / CSS Modules：
通过编译工具为类名添加哈希后缀（如 .button__2h7f），实现局部作用域。
◦ 优点：无需额外运行时逻辑。
◦ 缺点：依赖构建工具，无法隔离内联样式。

---

3. DOM 隔离

• 目标：防止子应用误操作基座或其他子应用的 DOM。
• 实现方案：
• 限制 DOM 查询范围：
子应用只能操作挂载容器内的 DOM（如 container.querySelector）。
• 沙箱容器代理：
劫持 document.getElementById 等 API，限制子应用访问外部节点。

---

二、iframe 通信实现

iframe 作为天然的沙箱，常用于微前端子应用隔离，但其通信需依赖特定 API。

---

1. 父子 iframe 通信

• postMessage API：
通过跨文档消息传递实现通信，支持跨域。

// 父窗口发送消息
const iframe = document.getElementById('my-iframe');
iframe.contentWindow.postMessage({
   
    
     type: 'update', data: 'Hello' }, '*');

// 子窗口接收消息
window.