微前端性能与安全

• 独立 CDN 部署的产物组织：版本目录、不可变文件名
• 缓存策略：长缓存与版本化 URL、缓存失效的取舍
• 缓存与发布的关系：快速回滚 vs 缓存污染

独立 CDN 部署的关键是「产物不可变 + 版本化寻址」：每个构建产物带有内容哈希（chunk 文件名含 hash）并归档到版本目录（如 /apps/orders/20260804.1/），部署只是「新增不可变文件」而非覆盖；子应用入口（remoteEntry、html entry）地址由配置中心指向具体版本目录，切换版本即切换入口。缓存策略上，带 hash 的 chunk 可长缓存（Cache-Control: immutable 一年），内容变了文件名就变、自然失效；而入口文件（remoteEntry/html）不能长缓存，用 no-cache + ETag 让浏览器每次校验，保证发布后新入口尽快生效。取舍点：长缓存省流量提升性能，但「入口短期缓存 + 版本切换」的组合中，CDN/浏览器缓存可能短暂提供旧入口，造成发布后的混合状态（部分用户旧版本）；为此可对入口做短缓存 + 版本参数绕缓存，回滚时切配置即可，无需重新构建。工程实践：CDN 与源站分离、跨域 CORS 头统一、SRI 完整性校验（长缓存配合哈希防篡改）、缓存键按版本隔离（灰度期间新旧版本缓存互不污染）。

回答按「不可变产物 + 版本目录 → 分层缓存（hash 长缓存 vs 入口短缓存）→ 发布与回滚的缓存协调」组织，核心是「内容寻址让缓存安全、入口寻址让发布可控」。

• 性能预算的维度：体积、加载时间、运行时开销
• 主子应用预算的分配模型：总量控制 + 分账
• 预算的执行：CI 门禁、监控回环与告警

微前端性能预算的制定分三步：定维度——体积预算（JS/CSS gzip 后体积，按「激活路径」计算页面实际加载总量而非各应用独立体积）、时间预算（首屏加载、应用切换耗时）、运行时预算（长任务、内存）；定基线——用 RUM 实测当前 P75/P95 与产物分析建立基线，按目标设备（如 4G 中端机）推算出总量上限；分账——把总量预算按激活路径拆分到主应用与各子应用（框架与公共依赖走 shared 单列预算，不计入单应用配额），每个子应用 CI 中校验自身预算并发布到平台汇总。协同要点：门禁分级——构建期硬性拦截（超预算失败）与发布期软告警（超预算允许发布但进入治理队列）；监控回环——RUM 按激活路径聚合实际加载量与耗时，与预算对比生成报告，发现「预算内产物实际表现差」（执行开销、渲染成本）时反推优化；预算随产品演进定期评审，避免僵化。

回答按「定维度 → 定基线 → 分账 → 门禁与回环」组织，强调微前端预算必须按「激活路径总量」而非单应用割裂计算，公共依赖单独列账，这是微前端预算与单体应用预算的本质区别。

• SnapshotSandbox 的快照与还原机制（激活/失活遍历 window 属性）
• ProxySandbox 的代理 + 值表机制
• 多实例支持、兼容性与性能的取舍

SnapshotSandbox（旧版默认）基于「快照 + 还原」：子应用激活时遍历并记录 window 全部可枚举属性到快照，卸载/切换时把 window 恢复为快照状态（清理子应用写入），再次激活时再还原子应用自己的修改。特点是兼容性最好（不依赖 Proxy、支持 IE），但只支持单实例（激活期间修改真实 window，切走后无法多应用并存），且遍历 window 全量属性有性能开销。ProxySandbox（新版默认）用 Proxy 代理 window：每个子应用拥有独立 proxy 与值表，激活时全局 window 被替换为该应用的 proxy，读写落在各自值表，支持多实例并存（互不污染）、激活切换零快照成本；代价是依赖 Proxy（不支持旧浏览器）、对不可代理属性（window.window、Symbol 等）存在盲区、高频访问有 trap 开销。取舍：需要多实例或追求隔离干净度用 ProxySandbox；面向旧浏览器或极端兼容场景用 SnapshotSandbox 并接受单实例约束。

对比题按「机制 → 能力（多实例/兼容/性能）→ 场景选择」展开：快照式是「记录-还原」，代理式是「拦截-分账」，两者的本质区别决定了单实例 vs 多实例的能力边界。

• 定时器与事件监听的拦截：替换 setTimeout/addEventListener 等
• 全局变量在值表中的写入与归属
• 卸载时的副作用恢复：清理与回滚

沙箱对三类副作用分别处理：全局变量——写操作落在子应用自己的值表（ProxySandbox）或快照（SnapshotSandbox），失活时恢复 window 原状，做到「写不出去、走时还原」；定时器——沙箱替换 window.setTimeout/setInterval/requestAnimationFrame 为包装实现，记录每个定时器句柄到子应用专属列表，卸载时统一 clear 全部句柄，防止切走后定时器继续跑（泄漏与副作用外溢）；事件监听——同样替换 addEventListener 为包装版本并登记监听器，卸载时按「沙箱期间注册的监听」精确移除，而不是粗暴移除全部（避免误删宿主监听）。恢复机制的工程要点：恢复顺序（先清理定时器、再移除监听、最后还原全局与 DOM）；注册与清理一一对应的登记表（句柄、目标、类型、捕获标志）；对未走包装的逃逸路径（第三方库直接调用原生方法）用原生引用的受控暴露兜底；清理失败要有补偿（重新挂载前的强制清理与监控告警），保证「进沙箱是干净的，出沙箱也是干净的」。

回答按「三类副作用的代理方式（变量分账、定时器登记、监听登记）→ 卸载恢复的顺序与精确性 → 逃逸兜底与补偿」组织，核心是「可恢复的前提是可登记」，沙箱必须掌握自己产生的每个副作用的去向。

• 原型链访问绕过 with 绑定的路径（Object.prototype 上的属性）
• Symbol.unscopables 改变 with 绑定语义
• iframe 兜底的原理与场景

with 的绑定规则是「标识符解析时查对象属性，但只影响『对象自身及其原型链上的属性』」，逃逸路径由此产生：原型链访问——沙箱内代码访问 Object.prototype 上挂载的全局方法（如 toString 原型链上的共享成员）不经过 with 绑定，且若宿主原型被修改，沙箱内代码可见宿主原型的新增成员，形成跨沙箱信息流；Symbol.unscopables——with 对对象属性的绑定可被对象的 Symbol.unscopables 控制（类数组对象用它排除 length 等属性），攻击者可在代理对象或对象上挂 unscopables 让特定标识符不绑定到代理、直接走外层作用域（逃到真实全局）。此外 Proxy 无法拦截：Symbol 属性访问、不可配置属性（window.window）、跨 realm 对象（iframe 的 contentWindow）。iframe 兜底：这些局限在 JS 语义层面无法根治，高安全场景用 iframe 作为独立全局执行（原生边界，无 with/Proxy 语义可绕），或 ShadowRealm 提供原生 realm 隔离，把「应用层沙箱」降级为「兼容性层」。

本题考沙箱理论边界：先讲 with 绑定规则的逃逸路径（原型链、unscopables），再讲 Proxy 的属性语义盲区，最后给 iframe/ShadowRealm 的原生隔离兜底，体现「知道沙箱的数学边界在哪」的深度。

• 主子应用生命周期事件的时序关系（子应用挂载于容器就绪后）
• 生命周期契约：参数（props/容器）、幂等与清理
• 对齐失败的场景：挂载过早、卸载过晚、异步竞态

对齐的含义是「子应用生命周期与基座页面生命周期同步」：基座路由命中 activeRule 时先保证容器就绪，再调用子应用 mount；基座离开路由时调用子应用 unmount，随后才可复用自己的容器资源——时序上「先容器后子应用、先子应用后基座」。契约设计：mount 接收明确参数（容器节点、props、路由信息），返回 Promise 表示挂载完成（含异步渲染完成）；unmount 返回 Promise 表示清理完成；两者都必须幂等（重复调用不报错、不叠加副作用）。对齐失败的典型场景：挂载过早——容器尚未插入文档就渲染，导致尺寸/样式错误（需等容器就绪或 DOMContentLoaded）；卸载过晚——子应用还在异步请求中基座已切走，回调操作已销毁的 DOM（需在卸载时中止异步与标记废弃）；竞态——快速切换 A→B→A 时旧请求响应覆盖新应用状态（需序列号/代际校验，只接受当前代的回调）。工程上以「生命周期状态机 + 代际令牌」统一管理，防止交叉时序问题。

回答按「时序对齐（先容器后子应用、先子应用后基座）→ 契约（参数、Promise、幂等）→ 失败场景（过早、过晚、竞态）与治理」组织，核心是生命周期不是「调钩子」而是「状态机 + 竞态治理」。

• Token 的存储与传递：受控注入 vs 明文广播
• 应用隔离的安全边界：沙箱、信任分级与资源控制
• 鉴权的一致性与失效处理

Token 传递的安全要点：基座统一持有 Token（内存或受控存储），通过受控通道（props 注入、沙箱内暴露、事件单次传递）下发子应用，避免 localStorage 明文广播（XSS 面大、跨子域共享风险）；跨域子应用用 HttpOnly Cookie（SameSite 策略）或 iframe postMessage 显式传递并校验来源；Token 刷新由基座统一处理，子应用收到新 Token 通过事件同步，避免各自刷新导致多套凭据。应用隔离的安全边界：沙箱隔离全局副作用（防子应用 A 篡改 B 的运行时）、样式与 DOM 边界（防样式注入与事件劫持）、子应用按信任分级（内部自研 vs 第三方嵌入差异对待，第三方应用用更严的隔离与权限）；资源侧控制子应用的网络出口（仅允许业务所需域）与存储使用（IndexedDB/Cookie 分区或清理策略）。鉴权一致性：所有子应用共用同一登录态（SSO），权限模型统一（基座下发用户权限、子应用按契约消费），失效处理（登出/超时）由基座统一触发并广播，避免「已登出但子应用还持有会话」的越权窗口。

回答按「Token 受控传递 → 应用隔离边界（沙箱、信任分级、资源控制）→ 鉴权一致性与失效」组织，突出「统一凭据、受控分发、分级隔离」的治理主线。

• 预加载策略：空闲预取、路由命中预取与优先级
• 切换优化：并行加载、资源复用、渲染保活
• 预加载的代价控制：带宽、内存与首屏竞争

预加载的目标是「把加载成本从切换时提前到空闲时」：策略分三档——按需加载（激活才加载，省资源但切换慢）、空闲预取（浏览器空闲或首屏后预取高频子应用的入口与核心 chunk，requestIdleCallback 调度）、命中预取（用户悬停/滑动到入口附近即预取，prefetch + Speculation Rules）；优先级上先预取「框架依赖与入口」，再按历史行为预测下一目标。切换优化：并行化——卸载旧应用与加载新应用并行（新应用就绪后一次性切换，避免白屏等待）；资源复用——公共依赖（框架、UI 库）不重复加载，靠 shared/缓存复用，切换只加载差异资源；渲染优化——切换期间显示过渡占位、新应用渐进渲染（先框架壳后数据）；保活——高频切换的应用用 keep-alive 保留实例，切换为显隐而非重建。代价控制：预加载不是越多越好，需限制预取体积与并发（避免与首屏关键资源抢带宽）、空闲预取不抢占主线程（空闲窗口内执行）、内存监控防止保活应用堆叠，预取命中率纳入指标评估策略有效性。

回答按「预加载三档策略与优先级 → 切换的并行与复用优化 → 代价控制」组织，核心是「预加载是投资，要用命中率衡量回报；切换优化是消除等待，用并行与复用实现」。

• 三类副作用的清理：DOM 监听、定时器/请求、全局状态
• 清理的工程手段：登记表、统一清理函数与依赖注入
• 清理不彻底的后果与检测

unmount 清理是防泄漏与防状态污染的关键：事件监听——移除子应用在 window/document 及全局元素上注册的监听（应用内部元素的监听随 DOM 移除自动释放，重点是全局监听），用「沙箱登记 + 精确移除」而非移除全部；定时器与异步——clearTimeout/Interval、中断进行中的请求（AbortController）、取消 RAF 循环，防止切走后回调继续执行操作已销毁的 DOM；Store 切片——重置子应用在全局 store 中的状态切片（Pinia/Redux 对应 reducer 卸载或状态清空），防止残留状态被下次挂载复用造成串数据；同时还原子应用改写的全局变量与 CSS 变量。工程手段：生命周期内统一收集副作用到登记表、unmount 时按序清理；框架层配合（React 的 effect cleanup、Vue 的 onUnmounted）天然覆盖组件内副作用，需补的是「组件之外的全局副作用」；检测与兜底：卸载后延迟检查（事件监听数量、定时器句柄、内存快照）对比基线发现清理不彻底的应用，用内存泄漏监控与「重复挂载一致性测试」把关。

回答按「三类副作用的具体清理（监听、定时器、Store）→ 登记表与框架清理的分工 → 检测兜底」组织，核心是「清理要有据可依（登记）、要彻底（全局 + 组件）、可验证（检测）」。

• 失败形态与降级目标：白屏 → 可控占位
• 降级链路：超时/重试/占位/恢复的编排
• fallback 的内容与恢复策略

降级的目标是「子应用不可用时不白屏」：加载链路编排为——超时（限制远程加载时间，如 5s）→ 重试（有限次退避）→ 占位（渲染本地 fallback）→ 恢复（后台重试成功后可重新加载或提示刷新）。fallback 设计分内容与行为：内容上提供「区域级占位」——该子应用区域渲染占位 UI（骨架屏、错误提示、重试按钮），页面其他区域（其他子应用、基座导航）保持可用，实现故障隔离的体验兜底；行为上占位组件支持手动重试、自动重试（定时探测）与「降级到静态缓存版本」（若之前缓存过该应用产物，可先用旧版本渲染）。工程要点：超时与重试参数可配置并进监控（降级率是核心指标）；fallback 路由要覆盖「激活即失败」与「运行中失败」（后者靠错误边界 + 占位替换）；恢复策略避免「恢复风暴」——同时失败大量子应用时阶梯式重试；降级动作全程上报（谁、什么原因、持续多久），支撑治理与告警。

回答按「失败形态 → 降级链路编排（超时/重试/占位/恢复）→ fallback 内容与恢复策略（区域占位、缓存降级、防恢复风暴）」组织，核心是降级不是「展示错误」而是「保持可用 + 可恢复 + 可观测」。

• 错误追踪的统一采集与跨应用归属
• 性能监控的跨应用拆解：激活路径与贡献度
• 边界环节（切换、通信、共享依赖）的专项监控

错误追踪建设：统一 SDK 采集 JS 异常、资源错误、接口错误与未处理 Promise，事件携带「应用栈」（当前页面上激活的子应用集合）与应用标识、版本、路由，上报后按应用与版本聚合；跨应用错误归属的关键是「边界标记」——错误发生在哪个应用沙箱内、经由哪条链路（props 调用、事件、远程模块）传播，传播路径要保留上下文（如调用方应用），避免「A 调 B 出错记到 A 头上」。性能监控拆解：整体指标（LCP/INP）之外，按激活路径拆解贡献度（主应用耗时、各子应用加载耗时、切换耗时），回答「慢在哪个应用的哪一段」；专项监控覆盖边界环节——应用切换耗时（卸载+加载+渲染）、跨应用通信延迟（事件/状态同步）、共享依赖加载（shared 命中率、重复实例检测）。落地要点：统一 traceId 串联「用户操作 → 应用切换 → 请求 → 错误」，切换与边界环节打点进同一条链路，错误与性能看板按「应用 × 版本 × 路径」多维聚合，形成「整体可感知、局部可定位、边界可解释」的监控体系。

回答按「错误归属（应用栈 + 边界上下文）→ 性能拆解（激活路径贡献度 + 边界专项）→ 统一链路」组织，核心是跨应用监控的难点在「归属」，解法是「应用栈 + 边界打点 + 统一链路」。

• iframe 的隔离强度与代价：原生全局隔离 vs 呈现问题
• Web Components 的封装能力与限制：样式边界 vs 兼容适配
• 按场景取舍：隔离需求、交互复杂度与生态

iframe 的隔离是浏览器原生级的：独立全局环境（JS 天然隔离，无逃逸面）、独立样式与历史栈，第三方库在 iframe 内运行几乎零适配成本；代价是呈现问题——弹窗/浮层被限制在 iframe 边界内（地图、日期选择器、下拉溢出被裁剪）、定位依赖坐标换算、跨域通信全靠 postMessage（序列化与延迟）、内存与连接开销大，且 SEO 与无障碍（焦点穿越）处理复杂。Web Components（customElement + Shadow DOM）提供应用层封装：样式边界（shadow 内不泄露不渗透）、DOM 组合自然（无裁剪问题）、通信走正常事件与属性（无序列化开销）；限制是 JS 隔离仍需配合沙箱（WebComponent 本身不隔离 JS 全局）、shadow 内表单控件与焦点管理有坑、老 UI 库对 shadow 适配成本高、浏览器兼容（现代浏览器已基本可用，但部分 polyfill 场景）。取舍：隔离需求最高且交互简单（嵌入第三方不可信内容）用 iframe；需要组合体验与性能（业务子应用）用 Web Components + JS 沙箱；成熟框架内嵌应用常用「WebComponent 容器 + Proxy 沙箱」折中，qiankun/micro-app/wujie 正是不同比例的组合。

对比题按「隔离强度、呈现体验、通信成本、生态适配」四个维度展开，结论是「强隔离给 iframe、好体验给 WebComponent」，主流框架都是二者与 JS 沙箱的折中组合。

• 团队边界与协作契约：接口、版本与发布窗口
• 版本管理：兼容矩阵、契约测试与依赖治理
• 独立发布的组织保障：门禁、灰度与回滚、责任边界

跨团队协作的根基是「契约代替协调」：团队间通过明确契约（子应用暴露的接口、共享依赖版本、事件协议、路由约定）协作，契约测试在 CI 自动验证，改动是否影响他方由机器判定；协作节奏上约定发布窗口与兼容承诺（如「子应用保持对基座 N-1 版本的兼容」）。版本管理：兼容性矩阵（主子应用版本组合）显式维护，共享依赖统一治理（框架版本策略、升级联合窗口），breaking change 必须走契约检测与通知流程。独立发布的组织保障：门禁（质量、契约、体积、安全扫描）自动化；灰度（按用户/流量）与回滚（配置级秒回滚）配套；责任边界清晰——每个团队对自身子应用的可用性负责，故障隔离保证单方问题不扩散，监控归属明确到团队，告警直达负责人。平台侧提供统一基座、脚手架、配置中心与监控大盘，把「协作成本」沉淀为「平台能力」。

回答按「协作契约化 → 版本治理（矩阵、依赖、breaking 流程）→ 发布组织保障（门禁、灰度回滚、责任边界）→ 平台化沉淀」组织，核心是微前端治理的本质是「用工程机制把跨团队协作从口头协调变成自动门禁」。

• 样式冲突形态：全局选择器、reset、字体与 CSS 变量污染
• 全局污染形态：window 变量、原型、事件与存储
• 系统化方案：构建期、运行时、治理三层

样式冲突常见形态：全局选择器互相覆盖（body/html 及无前缀类名）、reset 样式串扰（一个子应用的 reset 改掉所有应用的默认样式）、字体与图标库污染（同名 @font-face）、CSS 变量同名覆盖（--primary-color 互相改写）、动效与 z-index 层叠冲突。全局污染形态：window 上同名变量互相覆盖、原型链被改（Object.prototype 注入）、全局事件互相触发（同名自定义事件）、localStorage/IndexedDB 键冲突、Cookie 与导航劫持。系统化方案分三层：构建期——CSS Modules/命名前缀/BEM 约定、共享 reset 统一管理（基座统一注入并冻结）、图标字体按应用前缀；运行时——样式 scoped（选择器前缀）、Shadow DOM 边界（关键应用）、JS 沙箱（变量/原型/事件隔离）、存储键命名空间（前缀 + 应用域）；治理层——全局键与样式白名单登记、加载前后快照 diff 检测污染、lint 规则禁止裸全局选择器与无前缀全局变量、接入清单强制检查，形成「预防 + 隔离 + 检测」闭环。

回答按「两类问题的形态枚举（样式/全局）→ 三层方案（构建期预防、运行时隔离、治理检测）」组织，体现「先列现象、再分层治理」的工程方法，避免只答单点技巧。

• 基座统一 SSO 的模型与 Token 下发
• 子应用独立 token 的场景与同步
• SameSite Cookie 跨子域的机制（SameSite=None + Secure）与风险

三种方案按「统一程度」递进：基座统一 SSO——基座完成登录与 Token 管理，子应用通过受控通道获取，体验最统一（一次登录全应用可用）、凭据管理集中，但子应用依赖基座运行时（独立性弱）；子应用各自 token——每个子应用独立对接 IdP 或持有自己的凭据，独立性强（可脱离基座部署验证），但登录态割裂（多次登录体验）、凭据分散（安全面大）；SameSite Cookie 跨子域——把会话 Cookie 设为 SameSite=None + Secure 让子域共享，浏览器自动携带、无 token 传递代码，但要求全站 HTTPS、Cookie 暴露面大（XSS 可窃取）、且第三方上下文（iframe 嵌入）下 Cookie 携带受浏览器策略影响，数据驻留与合规审计也更复杂。取舍依据：同域/同信任域（同公司子域）且 HTTPS 完备时 Cookie 方案最省心；跨域独立团队用基座 SSO + 受控 token 下发；必须独立运行（第三方嵌入、完全解耦）才选各自 token 并做强一致性治理。工程上常见组合：基座 SSO 统一登录 + 子应用运行时注入 token + 同域辅助 Cookie，各自承担不同职责。

本题考方案权衡：先讲三种模型的机制与优劣，再按「信任域、HTTPS 完备性、独立性需求」给选型逻辑，最后给组合实践，体现「安全方案的取舍要看部署拓扑」。

• iframe 的固定开销：进程/线程、内存与网络栈
• IndexedDB 同源限制对跨域子应用的影响
• 缓解：资源复用、存储分区与替代方案

iframe 的性能损耗分几类：固定开销——每个 iframe 独立的渲染上下文与（在 Site Isolation 下）可能的独立进程/线程，内存占用随 iframe 数量线性增长（DOM、样式引擎、脚本环境副本），网络栈与连接管理也按 iframe 分账；切换开销——频繁创建/销毁 iframe 的初始化成本（文档加载、脚本执行），保活则占用常驻内存；通信开销——跨域 postMessage 的序列化与往返延迟。IndexedDB 同源限制：跨域子应用 iframe 无法访问基座域的 IndexedDB，各子域数据互相隔离，需要「跨域数据」时要么子应用数据放自己域（各存各的）、要么经基座中转（postMessage 委托读写）、要么走服务端。缓解手段：复用——不销毁 iframe 而用显隐切换（保活）摊薄初始化成本；瘦身——iframe 内只加载必要的运行时，公共依赖从基座传入；监控——按 iframe 维度统计内存与资源，识别泄漏；架构取舍——数据强交互场景评估「iframe 呈现 + 数据走服务端」或直接改用 WebComponent + 沙箱方案。

回答按「固定开销、切换开销、通信开销与 IndexedDB 限制 → 缓解（保活、瘦身、监控）→ 方案取舍」组织，核心是 iframe 的隔离成本是结构性的，缓解靠复用与瘦身、根治靠方案选择。

• 错误处理的层级模型：子应用内边界 vs 基座全局边界
• 向上抛的语义与代价：归属模糊、级联失败
• 分层策略：先本地兜底、再上报、再基座兜底

设计原则是「分层兜底，就近处理」：每个子应用内部建立自己的 ErrorBoundary（React）或错误处理钩子（Vue），渲染错误在本地降级（区域占位），保持自身可用并上报；未捕获的异步错误与全局异常由基座全局 handler 兜底。向上抛的取舍：错误向上抛的好处是统一处理（一个错误策略）与统一上报，代价是归属模糊（基座只知道「某个子应用出错」，需要上下文才能定位）、级联风险（错误在基座边界再抛导致整个页面崩溃）与隔离破坏（违背故障隔离原则）。正确分层：子应用内错误本地兜底（用户可继续用其他区域）→ 兜底动作与错误详情上报（带应用标识与边界上下文）→ 基座只在「子应用整体不可用」或「基座自身错误」时全局兜底；子应用错误是否需要「冒泡到基座界面层」取决于业务语义（如核心流程被阻断需要全局提示），但「崩溃」不应冒泡，冒泡的应是「状态」。工程要点：错误边界要覆盖渲染与事件处理器；跨边界（子应用调用基座能力出错）的错误由被调用方（基座）记录并从调用上下文归因。

回答按「分层模型（本地边界 → 上报 → 基座兜底）→ 冒泡的代价（归属模糊、级联）→ 冒泡语义（状态可冒泡、崩溃不冒泡）」组织，核心是「就近兜底 + 受控上报」而非「全量上抛」。

• preload/prefetch 的语义差异与适用资源
• Speculation Rules 的预渲染与预取机制
• 与框架预加载（qiankun preload、MF prefetch）的协作与去重

三类预加载按「强度与成本」分层：preload 加载当前页面即将使用的关键资源（立即高优先级，适合当前路由子应用的首屏 chunk）；prefetch 在空闲时预取将来可能使用的资源（低优先级，适合下一级路由的子应用入口）；Speculation Rules（现代浏览器）提供更高级的「预取（prefetch）+ 预渲染（prerender）」——按规则对目标 URL 预取文档或在后台完整预渲染页面（含 JS 执行、数据请求），用户跳转时瞬时呈现。微前端中的协作：框架层预加载（qiankun 的 prefetch 子应用、MF 的 prefetch remote）负责「运行时层面」预取子应用产物；浏览器层 Speculation Rules 负责「导航层面」预取/预渲染目标路由；两者互补而非重复——框架预取省掉子应用加载时间，Speculation Rules 预渲染省掉导航与渲染时间。工程要点：避免重复预取（框架预取的资源标记已加载，Speculation Rules 命中同 URL 时浏览器去重）；优先级协调（首屏关键资源 preload 优先于空闲 prefetch）；成本控制（Speculation Rules 预渲染会执行页面代码，对敏感/高耗资源页面慎用，用 rules 的 eagerness 分级）；回退（不支持 Speculation Rules 的浏览器由框架预加载兜底）。

回答按「preload/prefetch/Speculation Rules 的语义分层 → 框架层与浏览器层的协作分工 → 去重与成本控制」组织，核心是「框架预取省加载、浏览器预渲染省渲染，按浏览器能力分级回退」。

• 灰度的实施维度：用户分桶、流量比例与版本矩阵
• 独立回滚的边界：契约兼容、跨应用变更与数据
• 灰度与回滚的一致性保障

灰度实施：按用户分桶（userId/租户维度，保证同一用户始终命中同一版本组）与流量比例（1%→5%→50%→100%）阶梯放量；微前端场景下灰度的是「版本矩阵」——基座把不同用户路由到不同的子应用版本组合（A/B 两组入口配置），观察指标对比（错误率、性能、转化）后决策。独立回滚的边界：可独立回滚的前提是「版本间契约兼容」——子应用回滚到旧版本时，其与基座及其他子应用的接口契约（props、事件、远程 exposes）在旧版本下仍然成立；跨应用联合变更（同步改契约、共享依赖升级）不能单边回滚，否则新旧混跑产生不兼容组合；数据侧回滚要注意「数据前滚」（新版本写入的数据格式旧版本能否兼容读取）。一致性保障：灰度配置与回滚动作走同一配置中心且可审计；回滚按「版本矩阵快照」整组回退（避免只回滚一个应用留下混合状态）；灰度期间的监控按「桶」对比，快速发现异常立即回滚；灰度完成前保留双版本产物（不清理旧版），保证回滚有据可依。

回答按「灰度维度（用户分桶 + 版本矩阵）→ 独立回滚边界（契约兼容、联合变更、数据兼容）→ 一致性保障（矩阵快照回滚、桶级监控）」组织，核心是「独立回滚是有限度的，契约兼容是边界」。

• @module-federation/enhanced 的包能力：对 SSR、Vite、Rspack 的适配
• 多框架混用：框架无关的联邦加载与共享边界
• 现代工程注意点：双端一致性、类型与调试

@module-federation/enhanced 是 MF 2.0 面向现代工程的增强包：扩展了对 Vite/Rspack 的构建适配（@module-federation/vite、Rspack 原生插件）、提供 SSR 支持（服务端可加载远程模块并序列化共享状态，配合客户端水合保证双端一致）、以及多框架混用的运行时能力（框架无关的 loadRemote，宿主与远程可以用不同框架组合，只要各端共享的依赖策略正确）。SSR 注意点：远程模块在服务端的获取时序与缓存（Node 端预取产物、避免每请求重复拉取）、双端依赖单例一致性（shared 的 singleton 在服务端同样生效）、水合数据与远程渲染结果对齐。多框架混用注意点：框架运行时（React/Vue）本身要各自 singleton 且按应用边界隔离（React 子应用与 Vue 子应用共存时各自的 hooks 生态互不干扰）、共享依赖按「框架无关的纯库」优先共享（工具库、状态库）而非框架内核；类型与调试：远程模块的类型经 exposed 契约生成或声明文件维护、运行时错误用联邦调试面板与日志排查。工程上建议「框架级隔离、库级共享、契约级协作」。

回答按「增强包能力（构建适配、SSR、多框架）→ SSR 双端一致性 → 多框架混用的边界策略（框架隔离、库共享、契约协作）」组织，体现对 MF 2.0 现代工程面的系统认知。

• 三种共享方式的机制：构建期打包、运行时联邦、全局脚本
• 版本控制、按需加载与独立性对比
• 选型：升级节奏、体积与团队治理

三种方式按「打包时机」区分：npm 包——组件库作为依赖在各子应用构建期打包，版本各自锁定，升级按各团队节奏，最常用；优点是类型安全、tree-shaking、构建期校验，缺点是版本漂移（各应用组件库版本不一致、样式与 API 行为差异）、升级成本随应用数放大。Module Federation——组件库作为远程 exposes，运行时共享一份实现；升级即时生效（所有消费方同一版本）、体积最优（不重复打包），但要求组件库加载高可用（远程挂了全站受影响）、版本升级是全局变更（需灰度与回滚）、调试与类型维护成本高。external CDN——组件库打成全局脚本（window.XXX）由基座加载，所有应用引用同一全局；最统一、不参与各应用构建，但失去按需加载与 tree-shaking、组件库脱离构建体系（类型与版本靠约定）、全局命名污染风险。取舍：需要灵活升级节奏与类型安全选 npm（配共享配置包治理版本）；需要运行时统一与体积最优（高频共享、版本一致性强）选 MF；CDN 方案适合「必须绝对一致且更新极低频」的公共设施。工程上常见「npm 为主 + 关键 UI 层 MF 共享」的组合。

回答按「机制（打包时机）→ 三方案的优劣（版本、体积、独立性）→ 选型逻辑」组织，核心是「共享方式决定了版本治理模型」，升级节奏与团队结构是选型的第一变量。

• 统一监控的采集分层：SDK 能力归属与上报通道
• 重复上报的来源：双 SDK 实例、事件重复监听、切换重放
• 去重的工程边界：事件去重键、应用栈与版本

统一监控设计的关键是「一套 SDK、一个通道、分层归属」：主子应用统一接入同一 SDK（基座初始化、子应用复用实例或注册为子实例），上报走统一通道；每个事件携带「事件唯一键 + 应用栈 + 版本」。重复上报的来源与去重：双实例——基座与子应用各自初始化 SDK 造成同事件上报两次，用「SDK 单例 + 子应用注册（不重复初始化）」解决；事件重复监听——页面级事件（beforeunload、resize、error）被多个应用监听上报，用事件级别去重（相同事件键在时间窗内只报一次）与归属声明（该事件由哪个应用负责上报）；切换重放——应用切换时错误/性能事件在边界被重复采集（卸载中上报 + 重新挂载上报），用「会话内事件去重键（appName + 版本 + 事件指纹 + 时间窗）」合并。工程边界：去重不能过度——同一事件的「多视角」（如性能被主应用与子应用分别归因）可能需要保留，去重键要能区分「真重复」与「多视角」；上报去重与存储去重分工（SDK 层做窗口去重，存储层按指纹合并），错误事件按「首次发生 + 计数」聚合而非简单丢弃。

回答按「统一架构（一套 SDK 单通道）→ 重复来源枚举（双实例、重复监听、切换重放）→ 去重键设计与边界（区分重复与多视角、采集层与存储层分工）」组织，核心是去重要「合得起来、分得开」。

• 两种请求模型：网关/BFF 聚合 vs 子应用直连后端
• API composition 的收益：减少往返、聚合裁剪、统一鉴权
• 取舍维度：团队边界、性能、鉴权与独立部署

独立请求模型：子应用直接调用各自后端 API，链路最短、团队自治（每个团队管自己的接口），问题是一页面多请求（串行往返增加、移动端放大）、客户端需处理多接口聚合与裁剪、鉴权逻辑分散。网关/BFF 聚合模型：页面级 BFF 按「页面场景」提供聚合接口（一次请求返回页面所需全部数据），收益是减少往返、按端裁剪字段、统一鉴权与限流、隐藏后端拓扑（利于后端重构）；代价是 BFF 成为「另一个需要治理的应用」——与子应用的版本耦合（子应用页面结构调整时聚合接口也要变）、团队归属不清（谁维护聚合逻辑）、SSR 场景下 BFF 职责与渲染层叠加。取舍依据：团队边界——子应用完全独立（跨公司/跨组织）时用独立请求 + 各自网关；同一组织内页面级 BFF 聚合收益大；性能敏感（移动端、弱网）优先聚合；独立部署要求高时聚合层也要随子应用版本矩阵管理。实践上常用「BFF 聚合页面级数据 + 子应用内部细节接口直连」的混合模型，聚合层版本与页面版本绑定发布。

回答按「两种模型机制 → 收益与代价对比 → 按团队边界与性能取舍 → 混合实践」组织，核心是「聚合解决往返与分散，但引入版本耦合，按自治度与性能需求权衡」。

• 两种 i18n 模型：基座统一下发语言包 vs 子应用自管
• 一致性收益与独立性的权衡
• 语言切换的实时生效与资源加载

基座统一模型：语言资源由基座统一管理（语言包集中、切换逻辑统一），子应用通过 props/共享通道读取当前语言与翻译函数；收益是体验一致（一次切换全局生效、语言包无重复）、资源统一（语言包集中按需加载）；代价是子应用独立部署能力弱化（脱离基座无法验证多语言）、基座语言包成为集中变更点（子应用文案更新要等基座发版）。子应用独立模型：每个子应用自带语言包与切换逻辑，独立部署完整；代价是切换同步（基座切换语言需广播给所有子应用）、语言包重复加载与口径不一致（同一术语各应用翻译不同）、记忆偏好（语言偏好存储与恢复）需要约定。取舍：文案量大、术语规范严格的业务域（专业术语统一）倾向基座统一；子应用完全独立部署（跨组织）倾向自管 + 标准事件协议（基座广播 languagechange，子应用监听并切换）。工程要点：切换实时生效（语言变更事件 + 响应式更新）、语言包按需加载（切换语言才拉对应资源）、SSR 与首屏语言（先发注入语言标记避免闪烁）、翻译键命名空间化（避免子应用键冲突）。

回答按「两模型机制与收益代价 → 按业务域与部署独立性取舍 → 实时切换与资源加载工程要点」组织，核心是「i18n 的一致性来自统一，独立性来自自管，靠事件协议调和」。

• federationRuntime 的架构价值：运行时与构建解耦
• runtimePlugins 的扩展点：加载、共享、错误编排
• 在大型工程中的治理价值：统一策略、可观测、灰度

federationRuntime 把联邦运行时从「构建期生成的代码」变成「可独立升级的运行时模块」：大型工程中几十个子应用不用等构建器升级即可获得运行时修复与新能力（runtime 版本统一管理、按需升级），这是架构价值——运行时与构建解耦。runtimePlugins 提供统一扩展面：加载类钩子（loadRemote、errorLoadRemote）实现超时重试、降级与灰度路由；共享类钩子（resolveShare、beforeLoadShare）实现依赖版本策略（按环境选版本、动态回退）；可观测钩子记录联邦加载指标（成功率、耗时、版本协商结果）。在大型工程的治理价值：把「每个团队各自处理联邦错误」收敛为「平台统一策略」（一次开发全员生效）；通过插件注入监控与告警（联邦黑盒变可观测）；支持灰度（插件按用户维度切换远程版本）与降级（远程不可用自动切本地兜底）；snapshot 与插件结合实现依赖契约治理（版本漂移检测、强制回退）。工程实践：runtimePlugins 作为平台包统一发布、版本管理并做兼容性测试，插件代码本身纳入 CI 与灰度。

回答按「运行时架构价值（解耦）→ 插件扩展点分类（加载/共享/观测）→ 大型工程治理价值（统一策略、可观测、灰度）」组织，核心是「runtime 解耦让治理成为可能，plugins 把治理变成平台能力」。

• 资源边界的含义：子应用产物的边界与共享依赖归属
• 独立部署下的预算口径：激活路径总量 vs 单应用体积
• 预算的 KPI 化与跨团队治理

资源边界指「子应用产物的归属边界」：独立部署下每个子应用拥有自己的产物（自身 chunk 与部分共享依赖），预算必须先明确「哪些计入子应用、哪些计入共享」——框架与公共库走 shared/联邦共享时，单应用预算只计自身代码，共享部分按「激活路径」计一次。预算制定：体积预算按「激活路径总量」控制（主应用 + 激活子应用 + 共享依赖 ≤ 阈值，如 gzip 600KB），同时给每个子应用分配单应用体积配额（防个别应用超标拖垮整体）；时间预算按「加载 → 首屏 → 可交互」分段（LCP、切换耗时），KPI 化到版本：每次构建度量体积与耗时，与基线比对（超 10% 告警、超 20% 阻断）。治理：预算写入 CI 门禁与发布检查；平台侧按「激活路径 × 版本」聚合实际加载量，与预算对账；超预算治理聚焦「重复打包」（共享未生效）、「按需缺失」（路由级拆包未做）、「大依赖误引」；预算与 KPI 挂钩到团队（子应用体积超限影响该团队发布效率），保证「边界清晰、责任到团队」。

回答按「资源边界定义（归属与共享）→ 双口径预算（总量 + 单应用配额）→ KPI 化与跨团队治理」组织，核心是独立部署下「边界不清晰预算无从谈起」，共享依赖单列是微前端预算的独特要点。

• 加载顺序的影响因素：解析依赖、关键路径与连接数
• HTTP/2 多路复用消除队头阻塞与连接限制
• HTTP/3（QUIC）的进一步优化：0-RTT、无 TCP 队头阻塞

资源加载顺序由三件事决定：依赖关系（脚本执行依赖）、关键路径（首屏所需）、以及连接成本（HTTP/1.1 下每个域名连接数限制导致排队）。HTTP/2 多路复用改变了游戏：单个连接上并发传输多个流，消除 HTTP/1.1 的队头阻塞与连接数瓶颈，域名分片不再必要；「并发加载多个资源」的顺序敏感度大幅下降，加载顺序更多由依赖与优先级（preload 高优先级、prefetch 低优先级）决定而非连接排队。HTTP/3（QUIC）进一步把传输层从 TCP 换成 UDP 上的 QUIC：避免 TCP 级队头阻塞（丢包只影响单个流）、0-RTT 快速握手（减少连接建立延迟）、连接迁移（移动网络切换不断连）。微前端场景的利用：子应用独立部署在不同域名/CDN 时，HTTP/2 让多域资源并发无连接瓶颈（不必强行聚合到同域）；优先级编排用 preload/prefetch 与 script 的 async/defer 显式声明，配合 HTTP/3 的低连接开销提升切换时远程模块的加载速度；注意 HTTP/2 的 HPACK 与 QUIC 的 QPACK 压缩差异、以及 push 已废弃（改用 preload 语义）。工程要点：加载顺序的最终目标是「关键路径最短、无用加载最少」，协议演进解决的是「传输效率」，两者叠加才是性能最优。

回答按「顺序的决定因素 → HTTP/2 消除连接瓶颈 → HTTP/3 消除传输队头阻塞 → 微前端场景的编排实践」组织，核心是「协议解决传输、编排解决关键路径」，二者不是替代关系。

• 构建期拆包的两种方向：应用内拆包 vs 跨应用共享 chunk
• 独立部署对「共享 chunk」的约束（远程 chunk 归属与版本）
• 现代解法：MF shared 与运行时共享替代构建期共享

构建期拆包在单应用中解决「体积与按需」；微前端中多了一个维度——跨应用共享 chunk（公共模块抽成独立 chunk 供多个子应用引用）。取舍的根源是「独立部署」：共享 chunk 如果打在一个部署单元里，另一个独立部署的子应用加载它就要跨部署单元引用（版本、路径、缓存难治理）；如果各自打包公共模块又重复。权衡维度：共享收益（公共模块越大、复用方越多，共享收益越高）vs 独立部署成本（共享 chunk 的版本耦合、发布协调）。传统构建期共享（webpack splitChunks 跨 entry 抽公共 chunk）在微前端中受限于部署边界，容易变成「共享了但没法独立发版」；现代解法把「跨应用共享」从构建期移到运行时：Module Federation 的 shared 机制运行时协商共享依赖（共享一份、版本可控），应用内拆包继续用 splitChunks（路由级、组件级），形成「应用内构建期拆包 + 应用间运行时共享」的组合，兼顾体积与独立部署。工程要点：独立部署优先的团队用 MF shared；强一致且集中发布的团队才考虑构建期跨应用 chunk；共享边界按「变更频率」划分（低频变更的框架与工具库适合共享，高频变更的业务代码各自打包）。

回答按「拆包的两个方向 → 独立部署对共享 chunk 的约束 → 构建期 vs 运行时共享的取舍 → 组合实践」组织，核心是「独立部署是微前端拆包的第一约束，跨应用共享应交给运行时」。

• 硬约束与软告警的分级语义：阻断 vs 提示
• 阈值设计的依据：基线、波动与数据口径
• 预算检查的稳定性：口径统一、异常处理与趋势追踪

分级设计：软告警（threshold）——超预算阈值（如基线 +10%）时构建成功但告警，进入治理队列，适合「可解释的波动」（依赖升级、功能新增）；硬约束（fail）——超上限（如基线 +20% 或绝对值上限）时 CI 失败阻断发布，适合「确定性的退化」（重复打包、大库误引、按需失效）。阈值设计的依据：先以当前基线（近 N 次构建的中位数）为锚，波动容忍度参考「正常变更的体积影响」；体积类指标方差小，可用硬阈值 + 小容忍；耗时类指标方差大，用基线对比 + 大容忍（或仅软告警）。稳定性要点：口径统一（构建产物统计脚本与平台上报脚本同一实现，防止口径漂移误报）；异常处理（网络失败、缓存未命中导致的偶发偏差不能误杀，检查失败降级为告警并重试）；趋势追踪（预算检查记录历史，识别「温水煮青蛙」式缓慢增长，而非只看单次）；人工豁免流程（确有必要的超限走评审并限时回填基线，防止豁免机制破坏门禁权威）。

回答按「分级语义（软告警/硬约束）→ 阈值依据（基线 + 方差）→ 稳定性治理（口径、降级、趋势、豁免）」组织，核心是「门禁要拦得住真退化、放得过正常波动」。

• Critical CSS 的生成方案：构建期抽取 vs 运行时计算
• 内联策略：HTML 内联与异步加载剩余样式
• 取舍：缓存、体积与加载时序

Critical CSS 的目标是「首屏关键样式随 HTML 立即生效，避免样式表阻塞渲染」。生成方案分两类：构建期抽取——用工具（critical、penthouse、purgecss 等）对入口 HTML 分析首屏 CSS 并抽成关键样式文件，与 HTML 一起产出，特点是构建确定性好、无运行时开销，但需维护「视口/入口」配置，动态渲染与 SSR 模板的抽取需模板感知；运行时计算——页面加载时用 JS 遍历首屏 DOM 收集生效样式规则动态注入，精准但增加运行时成本与 FOUC 窗口，适合无法静态抽取的动态场景。内联策略：关键样式内联进 HTML head（

回答按「生成方案（构建期 vs 运行时）→ 内联与异步加载策略 → 缓存与预算取舍 → 框架与微前端落地」组织，核心是「内联换首屏速度，代价是缓存效率，按预算与场景平衡」。

• monorepo 下共享包的链接方式（symlink）与打包视角
• tree-shaking 生效条件：ESM、sideEffects 声明与作用域分析
• pnpm 的符号链接对依赖去重与摇树的影响

Tree-shaking 依赖「静态分析可达性」：模块必须用 ESM（import/export 静态语法）且包声明 sideEffects: false（或精确副作用文件），打包器才能安全删除未用导出。monorepo（pnpm workspace）的挑战：共享包通过 symlink 链接进工作区，打包器解析的是源码目录（未经构建的 TS 源码）或指向 dist——若共享包发布物是「大打包文件」（单文件全量导出）则摇树失效；pnpm 的符号链接结构（严格依赖隔离）让每个应用看到的共享包是同一物理文件，去重良好，但若共享包产物格式不佳（CJS、无 sideEffects 声明、barrel 文件全量导出），摇树依然无效。解法：共享包以「源码或 ESM 多文件产物」对外（让打包器直接分析源码、自己 tree-shake），package.json 声明 "sideEffects": false 与 exports 字段（精确入口、避免 index barrel）；配置打包器 resolve 到源码（如 webpack 的 exports 条件）或用 tsc/tsup 产出 ESM 构建并保留模块结构（非 bundle）；共享包内部避免「聚合导出文件」（re-export 整个 index），用路径级导出（import 到具体模块）；pnpm 场景注意依赖提升策略（hoisting）影响解析路径，配置 sideEffects 时用真实文件列表而非一刀切 false（有副作用的样式文件要保留）。

回答按「摇树原理（ESM + sideEffects）→ monorepo 与 pnpm 的挑战（symlink 解析、产物格式）→ 解法（源码/多文件产物、exports 精确入口、路径级导入）」组织，核心是「摇树失效大多源于产物格式与入口设计，而非打包器配置」。

• SRI 的机制：integrity 属性与 hash 校验、防 CDN 篡改
• 生产环境取舍：hash 的生成与更新、跨域 CORS 要求
• 微前端场景：远程 chunk 与动态加载的 SRI 落地

SRI 让浏览器在加载资源时校验其完整性（integrity 属性携带 base64 编码的 hash，加载后比对，不匹配则拒绝执行），用于防御 CDN 被攻破/篡改导致的供应链攻击（注入恶意脚本）。生产环境的取舍与要点：hash 生成与更新——hash 必须与产物绑定（内容变了 hash 就变），通常由构建工具（webpack 的 HtmlWebpackPlugin 自动注入）在构建期生成，构建产物的非确定性（时间戳、随机值注入）会导致 hash 失配，需保证产物可复现；跨域要求——SRI 对跨域资源要求 CORS（crossorigin 属性 + Access-Control-Allow-Origin），否则校验对跨域脚本不生效（且错误仍被遮蔽）；回退与兼容——老浏览器不支持 SRI 会直接忽略（可用性无损），但「hash 失配」时资源被拒会直接破坏页面（错误配置比没有更糟）。微前端场景的落地：静态 chunk 可内联注入 integrity（构建期生成）；动态加载的远程模块（MF remoteEntry、qiankun 远程 script）需要运行时注入 integrity（在注入 script 标签时带上对应 hash），hash 随版本清单维护；工程取舍：SRI 适合「静态资源 + 强安全要求」（敏感业务、金融级），代价是构建链路复杂化（hash 管理、产物可复现、CORS 配置），低风险内部系统可按需启用。生产实践：SRI + 版本化目录 + HTTPS 与 CSP 组合，形成资源完整性防线。

回答按「SRI 机制 → 生产要点（hash 生成与可复现、CORS、失配风险）→ 微前端动态加载落地 → 启用取舍」组织，核心是「SRI 是供应链防线，但配置错误比没有更危险」。

• scoped CSS 的实现：AST/正则改写选择器加前缀的机制与边界
• CSS-in-JS 的作用域化机制与运行时成本
• 两方案在隔离强度、动态样式与性能上的对比

scoped CSS 重写（qiankun 的 scoped css、Vue scoped 的构建期版本）原理是「改写选择器」：解析子应用样式表中的每条规则，给选择器附加子应用容器标识（如 [data-qiankun="app1"] 或属性前缀），使规则只命中容器内元素。运行时改写（qiankun）用正则/轻量解析逐条处理：可覆盖绝大多数规则，但边界包括——复杂选择器（:has、:is 嵌套）、@media/@supports 内的规则重写、@font-face/@keyframes 等 at-rule 不参与选择器改写、动态插入的 style 标签需额外 patch；改写还可能误伤「需要命中容器外部」的规则（如 body 样式、全局变量声明）。CSS-in-JS（styled-components、emotion）在 JS 侧生成带唯一标识（哈希类名）的样式并注入，天然作用域化：无需运行时字符串改写、支持动态样式（主题、props 条件）与 SSR 提取；代价是运行时成本（每次渲染样式计算与注入）、样式在 JS 包内（体积）、对第三方库样式无效（库自带 css 仍全局）。对比结论：scoped 改写适合「存量代码与第三方样式」的运行时隔离，边界在语法覆盖；CSS-in-JS 适合「自研组件」的构建期作用域化，边界在运行时成本与库样式；生产常用「构建期哈希（自研）+ 运行时 scoped（存量兜底）」组合。

回答按「scoped 改写的机制与语法边界 → CSS-in-JS 的机制与成本 → 适用边界与组合」组织，核心是「改写解决存量、注入解决自研，边界互补」。

• 单实例沙箱：同一时刻只激活一个子应用（快照/还原）
• 多实例沙箱：多子应用并存（Proxy 值表）
• 权衡：激活切换成本、隔离需求、内存与兼容性

单实例沙箱（如 qiankun 的 SnapshotSandbox、LegacySandbox）假设「同一时刻页面只有一个子应用激活」：激活时接管全局、切换时快照还原；实现简单（快照/记录-恢复）、兼容性好（不依赖 Proxy 或弱依赖），切换成本集中在「快照全量记录/恢复」与「切换的串行化」——不能同时存在多个子应用，后激活会覆盖前者的全局状态。多实例沙箱（ProxySandbox）支持多个子应用并存（各自独立代理与值表，同时激活互不污染），激活切换零快照成本（只换代理指向），隔离强度更高；代价是 Proxy 依赖（浏览器兼容）、对不可代理属性盲区、高频访问 trap 开销与内存（多套值表）。权衡要点：是否真有「多应用同屏并存」需求（dashboard 类页面多模块并存）——有则必须多实例；无则单实例更简单（内存省、无代理开销）；兼容性约束（老浏览器、极端环境）会压向单实例；性能敏感场景比较「快照成本 vs 代理 trap 成本」——高频全局访问多时多实例 trap 累积可能超过单实例快照的偶发成本。工程策略：框架默认多实例（现代浏览器）+ 老环境自动降级单实例（能力检测），把权衡交给运行时决策。

回答按「两方案的机制与成本（快照 vs 代理）→ 权衡维度（并存需求、兼容、性能）→ 运行时自适应策略」组织，核心是「多实例解决并存、单实例解决兼容，选择取决于真实场景」。

• 沙箱对 Worker 的代理边界：Worker 内的全局独立、无法被 with/Proxy 覆盖
• Worker 的创建拦截与脚本来源控制
• 跨线程通信的隔离与序列化边界

Worker 环境的特殊性：Worker 内是独立的全局作用域（self），与主线程 window 完全隔离——沙箱的 with/Proxy 代理只作用于主线程脚本执行上下文，Worker 内部的代码「天然不在沙箱内」执行，这是代理边界：沙箱能控制的是「谁创建 Worker、加载什么脚本」，而不是 Worker 内部运行时的全局。处理机制：创建拦截——沙箱包装 Worker 构造器，校验 Worker 脚本 URL（是否白名单内的子应用资源）、注入凭证与初始化参数（把沙箱标识、token 传给 Worker），防止子应用随意创建指向外部/内网地址的 Worker；来源控制——Worker 脚本必须来自子应用自身 CDN（同源或 CORS 白名单），配合 CSP 的 worker-src 约束；通信机制：子应用与 Worker 的 postMessage 通道在主线程上经过沙箱上下文，消息传递本身可被沙箱记录与审计（跨线程流量可见），但消息内容是克隆数据（结构化克隆），沙箱无法（也不应）篡改；SharedWorker 的共享连接按源（origin）管理，跨子应用的 SharedWorker 共享需显式设计（不同应用用不同端口/命名空间）。工程要点：Worker 内代码默认视为「沙箱外代码」，按信任分级处理（不授予主线程沙箱的隔离承诺）；对 Worker 的创建、脚本来源、消息内容做日志审计。

回答按「代理边界（Worker 内全局不受沙箱管控）→ 创建拦截与来源控制 → 通信隔离与审计」组织，核心是「沙箱对 Worker 的治理在边界（创建与通信），不在内部」。

• with 语句的可用性：严格模式禁用 with
• 严格模式对未声明赋值与 eval 语义的影响
• 沙箱的适配策略：非严格包装 vs 脚本改写

差异核心在 with 的合法性：严格模式下 with 语句是语法错误（SyntaxError），而 with + Proxy 沙箱依赖 with 把脚本作用域绑定到代理——直接对严格模式脚本套 with 会在解析阶段报错。因此沙箱的适配策略：把子应用脚本包一层非严格函数（function(global){ "use strict" 的代码包含在内部... }）再套 with，使外层 with 合法、内层代码保留自己的严格语义；或对脚本做预处理改写（把裸标识符访问重写成代理访问），规避 with。行为差异还有：严格模式下对未声明变量的赋值会抛 ReferenceError（而非静默创建全局属性）——沙箱内「写未知全局」从「落入值表」变成「报错」，行为更严格但可能暴露非严格兼容库的问题；严格模式的 eval 有独立作用域（eval 代码中的声明不外泄），与沙箱结合时 eval 内代码的全局访问需额外处理；this 语义差异（严格模式下函数 this 不自动装箱为全局对象）影响以 window.xxx 形式访问全局的库。工程结论：沙箱需要「包装执行 + 按脚本语义适配」，对严格/非严格混合的代码做分类处理，避免「严格代码被错误包装」或「非严格库在严格语义下崩」。

回答按「with 的合法性差异（严格模式禁用）→ 严格模式的赋值与 eval 语义差异 → 沙箱适配策略」组织，核心是「沙箱的执行包装必须尊重脚本自身的严格性语义」。

• Performance API 的指标体系：Navigation Timing、Resource Timing、User Timing、Long Tasks 等
• PerformanceObserver 的观察模式：buffered、回调与 entryType 过滤
• 工程要点：buffered 处理早期条目、去重与兼容

Performance API 提供浏览器性能数据的统一入口：Navigation Timing（页面导航各阶段时间）、Resource Timing（资源加载明细）、User Timing（performance.mark/measure 自定义打点）、Long Tasks（长任务）、Element Timing（元素渲染）、Layout Shift（CLS）等。PerformanceObserver 是其消费方式：以 observer 模式订阅 entryType（如 'resource'、'longtask'、'layout-shift'），异步回调接收新条目，比轮询 performance.getEntries() 高效且不阻塞。工程要点：buffered: true——页面加载早期的条目（导航、首屏资源）在脚本执行前已产生，observer 需要 buffered 选项回放历史条目，否则会漏掉关键首屏数据；回调内处理要轻量（把数据格式化后异步上报，不在回调里做重活）；条目去重与上报合并（同一资源多次观察避免重复上报）；兼容与回退——entryType 支持度逐版本演进（如 'element'、'largest-contentful-paint' 需检测），不支持时降级到 getEntries 快照或禁用对应指标；与 RUM 集成：用 User Timing 在应用层打关键节点（组件挂载、数据就绪），与浏览器指标拼成完整时间线，配合 PerformanceObserver 持续监控长任务与布局偏移。

回答按「API 体系（各 Timing + User Timing）→ Observer 的订阅与 buffered 机制 → 工程要点（早期条目、轻回调、兼容回退）→ RUM 集成」组织，核心是「Observer 是消费入口，buffered 与轻处理是生产可用性的关键」。

• longtask 条目的字段与含义（duration、startTime、attribution）
• 长任务与 INP 的因果关系
• 分片优化：任务拆分、空闲调度与线程迁移

Long Task API 提供长任务（主线程持续 >50ms 的任务）条目：duration（时长）、startTime（开始时刻）、attribution（归因：脚本 URL、容器）。诊断价值：INP 退化时，把 INP 事件时刻附近的 longtask 找出来——交互等待时间就是「事件排队到长任务结束」的时长，归因信息定位到具体脚本文件（配合 source map 到函数），分析任务内容（同步计算、大 DOM 操作、GC 停顿、复杂布局）。分片策略：任务拆分——把单次大循环/大计算拆成多片，用 requestIdleCallback / setTimeout(0) 或 async 分片让出主线程，避免单任务占用 >50ms；调度优化——渲染帧内的计算挪到空闲期，高优先级用户交互（输入处理）用 scheduler.yield 主动让位；线程迁移——纯计算逻辑移入 Web Worker，DOM 密集操作用文档片段/批量更新减少布局抖动；框架层面——虚拟列表（只渲染可视区域）、Memo/稳定引用（减少无效渲染）。落地闭环：以 longtask 时长/次数作为 INP 先行指标接入监控，优化后对比「长任务总时长」验证收益。

回答按「longtask 数据 → INP 因果归因（排队等待）→ 分片与调度策略 → 指标闭环」组织，核心是「长任务是 INP 的过程指标，拆分让主线程有响应能力」。

• 三种粒度的分割机制与触发时机
• 各粒度的收益与开销（请求数、体验、复杂度）
• 分割粒度的决策依据

三种粒度按「触发单元」区分：路由级分割（route-level）——按页面路由拆 chunk，进入路由才加载，是收益最大、成本最低的默认选择（与用户导航节奏一致，天然按需）；组件级分割（component-level）——对页面内「重型组件」（大图表、编辑器、弹窗内复杂模块）用 React.lazy / defineAsyncComponent 按需加载，让首屏只含可见部分；hook 级分割（hook/逻辑级）——把大型逻辑（数据处理、第三方 SDK 接入）拆成按需加载的模块（动态 import 包装），粒度最细，适合「特定用户操作才触发的逻辑」。取舍：粒度越细「首屏只加载需要的」越优，但每个分割点带来一次异步加载的延迟与复杂度（加载态、错误处理、边界条件），分割过细导致请求碎片化与维护负担。决策依据：按「体积 × 使用率」打分——大体积 + 低使用率（管理后台的重型页、少用的图表）优先分割；分割点选择「用户可感知的边界」（导航、交互触发点），让加载延迟落在交互的自然等待中；配合预取（hover 预取、空闲预取）抵消按需加载的延迟。工程上「路由级默认 + 组件级补强 + hook 级按需」，是标准的渐进组合。

回答按「三种粒度的机制与触发 → 收益与代价（延迟、复杂度）→ 决策依据（体积 × 使用率）→ 组合实践」组织，核心是「分割粒度匹配用户交互边界，用预取补偿按需延迟」。

• 自建 vs 第三方的核心差异：数据主权、成本与生态
• 第三方平台的能力与限制（采样、数据处理、隐私）
• 组合策略：双上报的职责分工与去重

自建埋点的优势：数据主权（原始数据全量可控、可自定义加工与关联）、低延迟低采样成本（直接进自家数仓）、与业务数据关联（用户、版本、A/B 组、后端 traceId）、隐私合规自主可控；代价：平台建设成本（采集、存储、报表、告警全自建）、指标口径需自己维护。第三方平台（GA 4、Sentry、SpeedCurve 等）的优势：开箱即用（无需建设）、生态成熟（报表、告警、回归检测）、专业统计处理；代价：数据在第三方（合规与数据出境审查）、采样与处理黑盒、字段与关联受限（难以与内部业务维度自由交叉）、依赖平台稳定性与定价。组合策略：职责分工——自建作为「权威数据源」（全量、关联业务、驱动 SLO 与告警），第三方作为「补充视图」（快速对比行业基准、团队自助查看）；或反过来：第三方做常规观测、自建做关键业务路径的深度归因；去重与口径——双上报场景统一采集（同一 web-vitals 库实例，两个目的地分别发送），口径一致（same 字段定义、same 上报时机），避免「两套数字打架」；按事件分级路由（普通指标走第三方、敏感/关键路径走自建）平衡成本与主权。

回答按「自建 vs 第三方的多维对比（主权、成本、生态、关联）→ 组合职责分工 → 口径与去重治理」组织，核心是「双通道不是重复，而是数据主权与开箱能力的互补」。

• 灰度与 Feature Flag 的层级：发布级灰度 vs 功能级开关
• 独立发布下的组合一致性：新旧版本 + 开关状态矩阵
• 回滚一致性：配置、Flag 与产物的协同回退

一致性风险的本质：独立发布下「哪个版本在跑」由配置中心决定、「哪个功能开」由 Flag 服务决定，两者组合出大量状态，任一组合不合理就出现「新代码配旧开关」「旧代码配新功能数据」的错配。保障机制：版本与开关联动——发布流程把「灰度批次 + Flag 默认值」作为发布包的组成部分（发布新版本同时下发该版本的 Flag 基线），避免新版本在旧 Flag 语义下运行；Flag 的默认值设计——新功能默认关闭（dead code 路径）、开启走灰度白名单，保证「发布新代码不等于上线新功能」，代码发布与功能上线解耦；灰度组合矩阵——「版本 × 开关」的组合在预发全量验证后再放生产灰度，灰度期监控按「版本组 × Flag 组」对比。回滚一致性：回滚不是「切版本」单动作，而是版本、Flag 与配置的原子回退——回滚工具把「版本入口 + Flag 覆盖 + 灰度分配」作为一个快照整体恢复；数据兼容——回滚前评估新版本写入的数据/状态旧版本能否承接（数据前滚）；缓存清理——回滚后 CDN/浏览器缓存与 Flag 缓存按版本失效，避免旧代码吃到新开关的残留。工程上把「版本 + Flag + 灰度」建模为统一发布对象（一个发布单），一致性由平台保证而非各团队口头约定。

回答按「一致性风险（版本 × Flag 组合错配）→ 联动机制（发布包含 Flag 基线、默认关闭）→ 回滚原子性（快照整体回退、数据与缓存协同）」组织，核心是「把版本、开关、灰度建模为原子发布对象」。

• 可观测性上下文的跨域透传载体：HTML 注入、请求头、响应头
• W3C Trace Context（traceparent/tracestate）与 baggage 的透传规则
• CORS 允许头配置与敏感字段（PII）的过滤治理

透传链路设计：SSR 阶段主应用在 Edge Runtime 生成页面时，把 trace 上下文注入 HTML（meta 标签或内联脚本变量）——子应用加载 remoteEntry 与后续 fetch 都从该上下文继承 traceId，保证「一次页面请求 → 跨域子应用资源 → 业务请求」共享同一条链路。载体分工：traceparent 用 W3C Trace Context 标准头承载（服务端 → 客户端 → 子应用请求头），tracestate 承载各系统的扩展状态，baggage 承载业务属性（用户会话标识、租户）；子应用侧请求时把从 HTML 继承的上下文写入 fetch 头（或由注入的 SDK 自动完成）；Server Timing 响应头（Server-Timing 携带各段耗时）用于把 SSR 服务端阶段（边缘渲染、数据获取）的时间回传到前端 RUM，与前端指标拼成完整时间线。CORS 限制：跨域子应用的 fetch 要携带 trace 头，Access-Control-Allow-Headers 必须显式放行（traceparent、tracestate、baggage、x-trace-id 等），预检请求要正确处理；敏感字段限制：baggage 中只能放非敏感业务标识（不放大头、token、PII），敏感数据走服务端透传（如带内传输）而非客户端可见头；trace 头本身对第三方暴露面可控（只含链路标识）。工程要点：SDK 统一封装「继承 - 注入 - 上报」三段逻辑，主子应用共用；对不支持的浏览器/环境降级（无头时生成新 traceId 并在边界关联）。

回答按「上下文注入载体（HTML → 子应用继承）→ 各头语义（traceparent/tracestate/baggage/Server Timing）→ CORS 放行与敏感字段治理 → SDK 统一封装」组织，核心是「跨域可观测性的关键是让 trace 上下文随请求边界正确继承与透传」。

• 共享依赖契约测试的目标：单例、版本协商与上下文完整性
• 加载顺序矩阵：宿主先/远程先、回滚、离线缓存
• 典型故障的断言：invalid hook call、上下文断裂、状态分叉

共享依赖契约测试验证「不同加载顺序下共享协商的结果正确」：断言维度——单例性（React 等框架全局只有一份实例）、版本协商（按 requiredVersion 命中正确版本）、上下文完整性（Provider/Context 跨应用不断裂）、状态一致性（共享单例状态不分叉）。顺序矩阵的构造：宿主先加载——宿主已实例化共享依赖，远程加载时复用宿主实例；远程先加载——远程先实例化，宿主加载时复用或按策略自载；版本回滚——远程回退旧版本后共享协商是否符合契约；离线缓存——Service Worker 缓存的旧 remoteEntry 与新宿主组合时协商是否被旧版本元数据误导。典型故障断言：invalid hook call（React 双实例——检查两个应用的 React 是否同一引用，可用 Symbol 标记检测）；上下文断裂（共享 Provider 创建的 context 因双实例而「同名不同物」，数据读取失败）；单例状态分叉（全局 store 双实例导致状态不同步）。落地：用契约测试框架（Vitest/Playwright）生成「加载顺序 × 版本组合」的用例矩阵，每个用例执行「加载 → 挂载 → 交互 → 卸载」，断言依赖身份（引用相等性）、协商结果（share scope 快照）与运行时行为；用例进 CI 并作为共享配置变更的回归基线。

回答按「测试目标（单例/协商/上下文）→ 顺序矩阵的四个关键场景 → 三类故障的断言方法 → CI 落地」组织，核心是「契约测试不是测功能，而是测『版本组合与加载顺序下的依赖身份与状态一致性』」。

• 沙箱初始化的成本构成：代理创建、快照遍历、环境准备
• 懒代理：按需创建子代理的机制与收益
• 快照 diff：只记录变更的还原与开销对比

沙箱初始化成本构成：全量代理创建（深代理所有全局对象）、快照全量遍历（记录 window 所有属性）、环境准备（polyfill、包装函数注入）。懒代理（lazy proxy）的核心是「按需创建」：代理对象创建时不深拷贝/深代理，子属性首次被访问时才创建对应子代理（get 陷阱中懒初始化），避免初始化时 O(N) 的代理链建设；收益是初始化快、内存省（只代理实际访问的路径），代价是首次访问多一次创建开销、代理语义的边界判断更复杂（懒创建的代理与直接值的一致性）。快照 diff 还原（SnapshotSandbox 类）的核心是「记录 vs 还原」：激活时快照、失活时还原，优化的方向是 diff——激活/失活时只记录「相对上次状态的差异」（变更过的属性），而不是全量遍历 window，减少遍历开销；快照适合「低频切换 + 属性变更少」场景，diff 化后成本进一步下降；代价是快照对「属性删除/属性描述符变化」需要额外记录（diff 不完整会漏还原）。取舍：高频切换场景懒代理（避免每切一次全量快照）；超大全局场景快照 diff（遍历成本高，只记变更）；组合实践——懒代理 + 变更记录（代理内记录写过的键，失活时只清理这些键），把「初始化成本」与「切换成本」都降到 O(变更量) 而非 O(全局量)。

回答按「初始化成本构成 → 懒代理机制与代价 → 快照 diff 机制与边界 → 组合策略」组织，核心是「优化的本质是把 O(全局) 成本降到 O(变更/访问) 成本」。