前端面试 P100:微前端 JS 隔离方案与资源生命周期
目前顯示中文(中國)原文
来源:方格前端讲面试 · 微前端架构中,一般是如何到JavaScript隔离的?,12 分 46 秒。
回看定位:00:28 隔离目标 · 01:49 Proxy
先说隔离目标
避免多个应用写同名全局变量、重复监听、共享原型污染或卸载后遗留任务。JS、CSS、DOM、路由、网络与存储是不同维度,不是隔离 window 一项就全部解决。
Proxy 沙箱
用应用独立的 fakeWindow 接住部分全局写入,读取时按规则回退真实环境;配合代码执行环境、全局名称映射与 API 适配,支持某些并存场景。
单独创建 Proxy 不会自动把任意已有脚本里的 window、globalThis 或裸标识符全改为代理。DOM API、函数 this、访问器、属性描述符和原型等也有兼容要求。
快照沙箱
激活前记录全局状态,停用时比较差异并恢复,保存应用自己的修改供再次激活。课程展示了这种基本模式,但浅快照容易漏掉删除、不可枚举与 Symbol 属性、嵌套对象修改和异步期间产生的变化。
同一个真实全局对象上的快照回滚,难以保证多个应用同时写同一状态互不干扰,常更适合受控单应用切换模型。
更强边界与成本
iframe 提供独立文档与 realm,可结合不同源和正确 sandbox 策略建立更强隔离,但有通信、样式和集成成本;同源 iframe 也不能默认当作安全隔离。Worker 有独立 JS 执行环境,却没有同样的直接 DOM 能力。
Shadow DOM 主要隔离 DOM/CSS 边界,不自动创建独立 JavaScript 全局。模块作用域减少顶层名称冲突,也不自动隔离全局 API 副作用。
无论方案,都要规定 mount/unmount、订阅、timer、请求、样式和路由的清理。具体 Proxy 示例及安全限制见 前端面试 P100:Proxy 沙箱为何不是安全边界。