沙箱隔离与安全

• 无界双层沙箱的职责划分与运行机制
• ProxySandbox 的代理拦截模型
• 性能（JS 执行、通信开销）与隔离强度（逃逸面）的综合对比

无界的双层模型是：子应用 JS 在隐藏 iframe 的独立 window 中执行，DOM 通过 WebComponent（shadowRoot）承载呈现，JS 隔离靠 iframe 的原生全局边界、样式与 DOM 隔离靠 WebComponent 边界，隔离强度最高——JS 层面几乎没有代理可绕过的逃逸面，第三方库在沙箱内缓存 window 引用也天然安全。qiankun 的 ProxySandbox 则用 with + Proxy 在同一 window 上下文内做读写代理，无 iframe 开销、激活切换快，但代理存在语义盲区（Symbol、不可配置属性、严格模式 with 失效等），逃逸面相对更大。性能上：无界需要 iframe 的创建与桥接通信成本，且 shadowRoot 对部分 UI 库的弹窗/定位有适配要求；qiankun 的 Proxy 拦截对高频全局访问有 trap 开销，但无进程级隔离成本。结论：追求强隔离与多技术栈混用选无界，追求低切换成本与生态成熟度选 qiankun。

对比题要建立统一坐标：隔离强度（谁更难逃逸）、性能（JS 执行与通信开销）、工程成本（生态适配）。无界强在原生边界，qiankun 强在轻量与成熟，回答要给出场景化结论而非单边站队。

• micro-app 以 customElement 承载子应用 DOM 的实现
• 样式隔离：Shadow DOM 与元素包裹（scoped）两种模式的切换
• JS 隔离：类 qiankun 的 Proxy 沙箱与元素级作用域约束

micro-app 用自定义元素 作为子应用容器：基座在 customElement 内注入子应用的 HTML/JS/CSS，浏览器对自定义元素的封装天然形成元素级边界。样式隔离有两档：默认通过给子应用根元素加唯一属性选择器（element 包裹 + 前缀选择器改写）实现轻量 scoped；开启 shadow 模式后用 Shadow DOM 实现最强封装，代价是样式穿透与表单交互需适配。JS 隔离复用 qiankun 的 with + Proxy 沙箱思路拦截 window 读写，同时结合元素作用域约束（子应用运行时绑定到所属容器）实现多实例并存时的隔离与切换。micro-app 的取舍是「以 WebComponent 为容器模型，沙箱能力可插拔」，比 qiankun 更贴合 Web 平台原生结构，但 shadow 模式下部分第三方库兼容性需要验证。

回答要区分「容器层」与「沙箱层」：customElement 解决 DOM 承载与样式边界，Proxy 沙箱解决 JS 全局隔离，两者组合构成 micro-app 的隔离模型，再点出 shadow 模式的代价与适配问题。

• ShadowRealm 的原生 JS 隔离语义（独立全局、不可访问外域对象）
• 与 Proxy 沙箱在逃逸面、性能、生态上的对比
• 提案成熟度与工程落地限制

ShadowRealm 是 TC39 提案（官方仓库现标注 Stage 2.7），提供原生隔离的 JS 执行环境：realm 拥有独立的全局对象与内置对象集合，外部对象只能通过值传递（对象需结构化克隆或包装）进入，从机制上杜绝了原型链污染、Symbol.for 共享等 Proxy 沙箱的常见逃逸路径，隔离强度接近 iframe 而无需 DOM 与通信负担。与 Proxy 沙箱的取舍：ShadowRealm 原生、无代理开销、逃逸面小，但要求子应用代码以模块形式进入 realm、跨 realm 对象必须包装传递，且 DOM 无法直接共享（需要桥接层），对依赖 DOM 全局的传统代码库改造成本高；Proxy 沙箱兼容性最好、DOM 全局可透传，但性能与逃逸风险并存。工程结论：新架构、模块化干净的代码适合 ShadowRealm 强隔离；存量系统仍以 Proxy 沙箱 + iframe 兜底为主，等提案落地后逐步引入。

本题考前沿隔离方案的取舍：先讲 ShadowRealm 的隔离语义（独立全局 + 值传递），再与 Proxy 沙箱对比逃逸面、性能与改造成本，最后给出按代码形态选择的工程判断，体现「新能力成熟度评估」的方法论。

• 各方案隔离机制的本质（构建期哈希/运行时注入/运行时改写/浏览器原生封装）
• 隔离强度、样式穿透能力与动态样式支持
• qiankun strictStyleIsolation 的实现方式与局限

五种方案按机制分三类：构建期方案——CSS Module 用哈希类名保证「自己写的样式不互相冲突」，但不防外部样式污染自身；CSS-in-JS 在运行时注入带唯一标识的样式，天然作用域化且支持动态样式，但增加运行时开销与 SSR 复杂度；运行时改写——scoped CSS（如 qiankun 默认模式）给子应用选择器加前缀，改动小、覆盖历史代码，但无法覆盖 @media/@font-face 等语法边界；浏览器级——Shadow DOM 提供真正的样式边界，隔离最彻底，但穿透（::part/::slotted）与全局变量继承需要显式设计；qiankun strictStyleIsolation 是给子应用容器加 shadowRoot 实现严格隔离，代价是子应用内弹窗/浮层挂载与全局样式依赖（如 antd 的 body 样式）会失效，需要适配。选型遵循「隔离强度与兼容成本成正比」，按子应用对全局样式的依赖程度分级采用。

对比题按「机制维度」分类记忆：哈希（构建期）、注入（运行时）、改写（运行时字符串）、封装（浏览器原生），再单独分析 strictStyleIsolation 的 shadow 实现与其兼容代价，最后给出分级选型策略。

• script 执行上下文注入（with 包装 + eval 执行）
• fetch 拦截与资源请求的重定向/凭证处理
• 动态 import 的沙箱化与运行时 resolve

资源加载隔离分三块：script 执行——qiankun 等框架用 import-html-entry 把远程 HTML 中的 script 内容取出，用 with(proxy) + eval 在沙箱上下文中执行，使脚本内的全局读写都经过代理；fetch 拦截——框架 patch 子应用运行时的 fetch/XMLHttpRequest，改写相对路径为子应用基址（对齐 publicPath），并可控制凭证携带与请求头，避免资源请求错发到主应用域名；动态 import——运行时把 import() 的解析重定向到子应用基址，或在模块联邦场景下由联邦运行时接管动态远程加载，确保按需 chunk 从子应用自己的 CDN 拉取。三者协同保证「代码执行在沙箱、资源请求归自己」。局限：补丁只能覆盖框架执行路径内的行为，子应用内部自己创建的 Worker、原生 import 映射（import maps）等仍可能绕过，需靠契约约束与审计兜底。

回答按「执行、请求、模块解析」三条链路组织，讲清每条的拦截点与实现（eval + with、fetch patch、import 重定向），最后点明补丁式方案的边界（绕过面），展示对加载隔离的系统理解。

• 原型链污染：经由共享原型对象修改全局行为的路径
• Symbol.for 全局注册表跨沙箱共享
• iframe 通信劫持与防御

常见逃逸路径有三类：原型链污染——沙箱内代码修改 Object.prototype 等共享原型（如给原型加属性或改方法），由于宿主与沙箱共享同一套内置原型，污染会波及宿主与其他子应用，造成全局行为篡改；Symbol.for 同理，其全局注册表（GlobalSymbolRegistry）跨 realm 共享，沙箱内 Symbol.for 注册的符号在沙箱外可见，可被用于标记隐藏通道；iframe 通信劫持——沙箱内 iframe 通过 parent/top 访问宿主 window，或用 postMessage 与外部通信绕过代理边界。防御策略分层：加固沙箱——冻结关键原型（Object.freeze 原型或代理原型读写）、拦截 Symbol.for/全局构造器；隔离边界——iframe 通信强制来源校验与协议白名单，postMessage 只允许显式声明的消息通道；治理层面——子应用信任分级、CSP 收敛执行面、逃逸审计（加载前后全局快照 diff）。

本题考「逃逸面枚举 + 防御」：先逐个讲清三类路径的机制（为什么能绕过去），再给分层防御（原型冻结、边界校验、审计治理），体现「知道怎么逃才知道怎么防」的安全方法论。

• Site Isolation 的浏览器进程级隔离语义
• 微前端沙箱运行在同一站点下的局限与互补
• 跨站子应用（iframe/COOP/COEP）与 Site Isolation 的交互

Site Isolation 是浏览器进程级安全机制：不同站点（site）的页面放入不同渲染进程，阻止跨站数据通过内存侧信道等被窃取，属于浏览器底层安全边界；微前端沙箱是应用层 JS 隔离，运行在同一站点下的同一渲染进程中，目标是业务级隔离（全局变量、样式、状态），而非安全级进程隔离。二者的协同：微前端子应用若来自不同源（如 iframe 方案或跨域 remoteEntry），浏览器会按 Site Isolation 天然分进程，获得浏览器级隔离兜底；同源子应用则共享进程，应用层沙箱承担全部隔离职责，若被逃逸则影响同进程的其他应用。冲突边界：强行用沙箱把跨站内容「同源化」会破坏 Site Isolation 的安全收益（相当于把不同信任级内容混入同一进程），正确做法是保持跨源边界（cross-origin iframe、COOP/COEP 声明），让浏览器安全模型与业务沙箱各司其职。

本题考「安全层级」认知：先区分进程级（Site Isolation）与应用级（微前端沙箱）两种隔离的职责与信任模型，再讲协同（跨源子应用获得浏览器兜底）与冲突（盲目同源化削弱安全收益），最后落到 COOP/COEP 等声明式边界的正确姿势。

• sandbox 属性的默认完全限制语义与白名单授权
• allow-scripts/allow-same-origin/allow-forms 等关键权限的组合风险
• 微前端中 iframe sandbox 的使用边界

iframe sandbox 属性默认启用「完全限制」：无脚本、无表单提交、无弹窗、无同源、无顶层导航，通过白名单关键字逐项放权：allow-scripts 放行脚本、allow-forms 放行表单、allow-popups 放行弹窗、allow-same-origin 放行同源权限（Cookie/localStorage 等）、allow-top-navigation 放行顶层导航。微前端中通常需要 allow-scripts 运行子应用，但「allow-scripts + allow-same-origin 同开」是危险组合：同源时脚本可以移除 sandbox 属性自身（sandbox 对同源文档的脚本约束可被脚本解除），从而完全逃逸；因此若子应用可执行脚本，要么不同源（数据隔离靠跨源），要么不授予 allow-same-origin。此外 sandbox 不限制 iframe 内的网络请求本身，DDoS 面需配合 CSP 与出口管控。

本题考安全配置的语义细节：先讲 sandbox 的默认拒绝模型与授权关键字，再重点强调 allow-scripts + allow-same-origin 的组合风险（可自解除沙箱），最后给微前端场景的配置建议，体现对安全边界的准确判断。

• 沙箱并存下 window 全局属性、全局事件与 CSS 变量的冲突场景
• 命名空间约定：前缀、域划分与注册表
• 冲突治理：激活隔离、白名单与审计

多沙箱并存时冲突来自三处：window 属性——各子应用声明同名全局变量（如 window.APP、window.userInfo），后加载覆盖先加载，造成读取错乱；全局事件——各子应用监听同名自定义事件（如 refresh、logout）互串触发；CSS 变量——子应用定义同名 Custom Property（--primary-color）污染全局变量作用域，影响其他应用样式。治理的核心是命名空间化：全局属性统一前缀加应用域（如 _MF_APP1、APP1_xxx），并通过注册表登记、激活时校验归属；事件用「应用域名.事件名」双层命名并统一在基座注册转发；CSS 变量限定在子应用容器根上声明（配合 scoped/shadow 边界），或使用 CSS 变量命名空间（--app1-*）。同时用白名单约束子应用可写的全局键，配合加载前后快照 diff 审计未声明的污染。

回答按「冲突三来源 + 三类治理」组织：每类冲突给出具体场景，再给对应的命名空间约定（属性前缀、事件域、CSS 变量容器化），最后落到白名单与审计的制度化约束，体现治理的系统性。

• 沙箱开销的来源：Proxy trap 触发频率与代理链深度
• 高频全局访问（框架运行时、轮询）下的开销放大
• 量化方法与优化：减少代理深度、访问缓存、按需代理

沙箱开销主要来自 Proxy：每一次对代理对象的属性读写都会触发 get/set trap，trap 内做查找、记录、回写等逻辑，频率一高（框架运行时频繁读 window、轮询、大量全局状态读写）开销被放大；代理深度则指嵌套对象（window.xxx.yyy）每层都要包代理，链越长创建与访问成本越高，深拷贝式代理对大型全局对象还带来初始化成本。工程影响可直接反映在渲染帧率：主线程被 trap 占用后，长任务增多、帧间隔拉长，尤其在低端设备上表现明显。量化方法：用 Performance 计时对比有无沙箱的同场景耗时、统计 trap 调用次数（代理内埋点计数）、观测长任务与 FPS。优化方向：减少代理深度（浅代理 + 按需子代理）、对高频只读属性做缓存快照、懒代理（首次访问才创建）、以及把高频访问路径移出沙箱（如 direct access 白名单）。

本题考性能评估方法：先定位开销来源（trap 频率 × 单次成本、代理深度），再讲对帧率的影响链路（主线程占用 → 长任务 → 掉帧），最后给量化手段与优化策略，体现可测量的性能工程思维。

• with 语句把代码作用域绑定到 Proxy 的机制
• Proxy 的 get/set 拦截与 fakeWindow 值表
• 严格模式限制与逃逸边界

实现步骤：创建 Proxy（fakeWindow），其 get 陷阱按「先查自身值表、再查真实 window、最后返回 undefined」的顺序解析属性；set 陷阱把写入落在值表而非真实 window；用 with(fakeWindow) 包装子应用脚本，使脚本内未声明的变量读写都经过代理，实现「读可回退到全局、写留在沙箱」。常用技巧包括：has 陷阱配合全局变量判定、delete 陷阱处理删除语义、getOwnPropertyDescriptor 等反射陷阱保证属性描述一致。边界：严格模式下 with 不可用，需把脚本用非严格函数包一层或改用运行时改写；代理无法拦截 Symbol 属性、不可配置属性（window.window）与跨 realm 引用；通过 eval/Function 动态执行的新代码若不在包装内也会逃逸。因此该方案适合「兼容性优先、信任度中等」的场景，高安全场景需 iframe/ShadowRealm 兜底。

本题考实现细节：按「代理值表 → with 包装 → 陷阱设计 → 边界」的步骤还原实现，再明确严格模式与属性语义的局限，展示从原理到代码的还原能力。

• 三种方案解决冲突的机制差异：命名约定、构建期哈希、浏览器封装
• 隔离强度与协作成本
• 微前端场景下的组合选型

BEM 靠命名约定消解冲突：块（block）前缀让选择器具备唯一性，零构建成本、团队协作友好，但依赖人遵守约定，冲突只是「概率降低而非消除」；CSS Modules 在构建期把类名哈希化，机器保证唯一，冲突基本消除，代价是需要构建支持且动态拼接类名/第三方库全局样式仍需处理；Shadow DOM 用浏览器原生封装把样式隔离在边界内，隔离最彻底，但样式穿透（::part、::slotted）、全局继承（字体、CSS 变量）与 UI 库兼容需显式设计。选择逻辑：团队约定与历史包袱重选 BEM（渐进）；新工程且构建可控选 CSS Modules（机器保证）；需要真边界（微前端子应用、第三方内容嵌入）选 Shadow DOM；生产实践常组合——模块内用 CSS Modules、跨应用边界用 Shadow DOM 或 scoped 兜底。

回答按「约定—构建—浏览器」三档隔离强度组织，每档讲机制、成本与局限，再给微前端场景的组合选型，体现「按威胁模型选隔离强度」的工程判断。

• eval/Function 绕过 with 包装作用域的原理
• new Function 构造作用域的全局特性
• CSP 的 script-src 与 unsafe-eval 约束

风险在于动态代码的「执行上下文不受包装」：with 包装只作用于脚本字面量作用域，eval 直接执行的字符串、new Function 创建的函数体都是「独立作用域」——eval 使用调用处作用域、Function 则始终在全局作用域构造，因此其中对 window 的读写绕过沙箱代理（若代码来自外部注入更直接构成 XSS 面）。CSP 是浏览器级兜底：script-src 策略禁止内联脚本，而 eval/new Function 属于「unsafe-eval」管控范围——不配置 'unsafe-eval' 时浏览器直接拒绝执行这些动态代码（报 EvalError），从而把「沙箱管不住的执行方式」在平台层封死。工程实践：沙箱内对 eval/Function 做替换或拦截（如代理 Function 构造器、对 eval 传参做白名单校验），同时配合 CSP 关闭不必要的 unsafe-eval，双保险约束动态执行面。

本题考「执行面治理」：先讲清 eval/Function 为何能逃逸（作用域不经过包装），再讲 CSP 的 unsafe-eval 如何在浏览器层兜底，最后给沙箱内拦截 + CSP 双保险的组合方案。

• CSP 策略指令（script-src、style-src、connect-src）与微前端远程资源的声明
• 严格 CSP（nonce/hash）与动态加载的冲突
• 常见绕过：JSONP、重定向、unsafe-inline 组合

CSP 通过声明式指令约束页面可加载与可执行的资源：script-src 限定脚本来源，style-src 限定样式，connect-src 限定请求目标。与微前端协同的关键是远程资源声明：子应用的 remoteEntry、chunk 与样式必须显式加入白名单（域名或 nonce/hash），否则被 CSP 阻断；qiankun 的 import-html-entry 拉取远程 HTML 内联执行脚本的方式与严格 CSP（无 unsafe-inline）冲突，需改用 nonce 注入或走模块加载通道。绕过方式常见的有：允许 JSONP 端点时可利用其回调函数执行（script-src 白名单了可被当脚本加载的 JSONP 接口）；CSP 允许的域名下存在可上传/可控内容时形成二次注入；'unsafe-inline' 与 'unsafe-eval' 放行面过大使策略形同虚设；重定向链把白名单域跳转到攻击域。防御：使用 nonce/hash 严格策略、收敛白名单、开启 report-only 观察后强制、禁止不安全关键字。

本题考 CSP 的工程配置与攻防意识：先讲与微前端远程资源的协同（白名单声明、与 import-html-entry 的冲突），再枚举常见绕过路径，最后给严格策略与报告机制的建设方法。

• 原型链污染的攻击路径与危害
• 加固：冻结原型、代理原型读写、白名单
• 检测与审计兜底

攻击路径是修改共享原型：子应用代码对 Object.prototype/Array.prototype 等赋值或 merge 类操作污染原型，使「看似无关的对象」获得被注入的成员，进而覆盖宿主逻辑（如某对象 .isAdmin 被注入为 true）或在沙箱外触发恶意行为。加固措施分三层：阻断写入——进入沙箱前 Object.freeze 关键原型（或对原型对象套 Proxy 拦截 set），使污染操作静默失败或抛错；收敛入口——对 JSON.parse 结果、deepMerge/assign 等递归操作做白名单校验（拒绝 proto、constructor.prototype 等键）；隔离边界——关键数据用无原型对象（Object.create(null)）承载，杜绝原型继承链。检测兜底：加载前后对关键原型做快照 diff，检测到原型变化即告警，同时 CSP 与内容信任分级降低利用面。

本题考「攻击路径 + 防御纵深」：先讲污染如何发生与危害，再按「阻断写入、收敛入口、隔离数据」三层给加固，最后落到快照 diff 的检测闭环，体现纵深防御思路。

• Proxy trap 的调用成本与访问频率放大效应
• 优化：读写缓存、懒代理、快照、移出高频路径
• 量化观测方法

影响机制：每次属性访问触发 trap，trap 内多一次函数调用与查找逻辑；当访问频率极高（渲染循环中读 window 配置、动画帧内读全局状态、框架响应式系统高频 get）时，trap 成本按访问次数线性放大，成为主线程瓶颈，表现为长任务增多与掉帧。优化手段：读写缓存——对高频只读属性首访后缓存结果，避免重复 trap；懒代理——子代理在首次访问时才创建，减少深层代理的初始化与嵌套成本；快照——把沙箱状态定期快照到普通对象，高频路径直读快照；路径迁移——把高频访问的全局值在进入沙箱时注入为局部变量（如 const env = sandbox.env），使渲染循环内不再触碰代理；对纯计算逻辑用普通函数而非代理对象承载。观测上通过 Performance.mark 分段计时、trap 计数与长任务监控对比优化前后收益。

本题考「性能归因与优化」：先讲 trap 成本 × 频率的放大关系，再按「缓存、懒化、快照、移出」四个方向给优化，最后提量化观测，强调用数据驱动优化而非凭感觉。

• 加载前后 window 快照 diff 的检测原理与实现
• hook Function/eval 构造器监控动态执行
• Proxy 陷阱日志记录逃逸尝试与审计闭环

三项手段构成检测闭环：window 快照 diff——子应用加载前对 window 的可枚举属性做基线快照，卸载后（或运行中定期）对比 diff，新增/删除/改写的全局键即逃逸或污染痕迹；实现上注意过滤合法项（沙箱自身注册的全局），用白名单收敛告警噪声。hook Function/eval——包装 Function、eval、setTimeout('string') 等动态执行入口，记录调用方堆栈与代码片段，识别未经沙箱包装的动态执行（逃逸或潜在 XSS 源）。Proxy 陷阱日志——在沙箱 Proxy 的 get/set/delete 陷阱中埋点记录访问模式，发现对敏感键（如 proto、prototype、parent/top）的异常访问尝试，标记可疑行为。工程化要点：三项日志统一汇聚、按应用与事件归类、与监控大盘打通形成告警；审计结果反向驱动加固（如发现高频原型访问则冻结原型）。同时注意埋点本身的开销与误报率治理。

本题考安全可观测性：分别讲清三项手段「检测什么、如何实现、局限在哪」，再讲统一汇聚与告警闭环、以及审计反哺加固，展示把安全能力工程化的完整链路。