聊聊前端模块联邦的运行时隔离方案，真的能安全加载远程代码吗

模块联邦（Module Federation）刚出现时，很多人把它当成微前端的终极答案：远程模块按需加载、依赖共享、运行时集成，看起来既优雅又强大。但一旦远程代码来自不同团队、不同仓库，甚至不同公司，问题就来了——我们真的能安全地加载并执行别人的代码吗？不少方案宣称通过沙箱、Proxy、iframe 或 ShadowRealm 实现了“运行时隔离”，但隔离的边界到底在哪里，值得认真聊聊。

模块联邦解决的是共享，不是安全

Module Federation 的核心是运行时容器和共享依赖。它让主应用可以动态加载远程入口，解析远程模块，并协商 React、Vue 等 singleton 依赖的版本。这套机制极大提升了构建期的解耦和运行时的组合能力，但它从设计之初就不是安全沙箱。远程代码一旦被加载，默认就拥有和主应用相同的执行环境：同一个 window、同一份 localStorage、同一套 cookie、同一个 DOM。它可以发请求、改路由、劫持事件、读取 token，甚至污染原型链。模块联邦的 shared 机制反而可能放大风险：一个恶意的远程模块可以覆盖共享依赖，让主应用和其他远程模块都用到被篡改的实现。

常见运行时隔离方案，各自能做什么

主线程沙箱是最常见的方案，比如用 Proxy 拦截 window，快照并恢复全局变量。它能减少命名冲突和部分全局污染，适合防“误操作”，但很难防“恶意代码”。因为浏览器主线程里的 JS 并没有内核级权限隔离，恶意代码可以通过 `iframe.contentWindow`、`document.createElement('script')`、`Function` 构造器、原型链等路径绕过 Proxy。沙箱更多是工程约定，不是安全边界。

iframe 是浏览器原生最强的隔离手段。跨域 iframe 拥有独立的 JS 执行环境和同源策略边界，配合 `postMessage` 通信，可以真正把不可信代码关起来。代价也很明显：通信异步、UI 集成复杂、弹窗和路由受限、性能开销大，而且如果同源部署，隔离强度会大打折扣。

Web Worker 提供线程级隔离，没有 DOM，适合跑计算、校验、数据处理等逻辑。但它无法直接渲染 UI，通信也要序列化，不适合作为完整微前端方案。Shadow DOM 解决的是样式隔离，不是 JS 安全；ShadowRealm 提案能提供更干净的 JS 执行环境，但兼容性和 DOM、网络等能力隔离仍有限，短期内不能当作万能钥匙。

远程代码的威胁到底在哪

远程代码最大的风险是“同源即全权”。只要它在主线程执行，就能读取当前域下的存储、发起携带凭证的请求、操作页面内容、窃取用户输入。供应链攻击也很现实：远程入口文件被篡改、CDN 被劫持、构建产物被注入，都会让主应用瞬间失守。模块联邦的动态加载还让 SRI 和 CSP 更难统一落地：remoteEntry 往往需要 script-src 放行，内部 chunk 由运行时自行加载，校验链条容易断裂。

可落地的分层策略

第一层是信任模型。内部团队代码和第三方代码必须区别对待。可信代码可以用模块联邦加沙箱治理，不可信代码就不要放主线程，优先跨域 iframe 或 Worker。

第二层是传输与构建安全。HTTPS、CSP、SRI、签名清单、版本锁定、私有 registry、最小权限发布，这些比运行时沙箱更基础。远程入口最好有完整性校验和回滚机制。

第三层是运行时治理。主线程沙箱用于防冲突、防误改全局；关键依赖避免 singleton，状态尽量隔离；远程模块只暴露最小 API，通过消息或契约通信。同时加上超时、熔断、降级和监控，避免远程故障拖垮主应用。

总结

模块联邦的运行时隔离能提升工程稳定性，减少全局污染和依赖冲突，但它不是安全沙箱。只要远程代码在主线程执行，它就拥有同源权限，任何 Proxy 沙箱都难以提供真正的安全保证。安全加载远程代码，本质是信任边界问题：可信代码做好供应链和运行时治理，不可信代码请用 iframe、Worker 等强隔离环境。没有银弹，只有与威胁模型匹配的边界设计。