三层以上 iframe 嵌套会直接触发性能断崖，表现为加载延迟叠加 30–80ms、内存陡增、postMessage 断链、iOS Safari 中 contentWindow 为 null 或 onload 丢失，必须卡死为硬边界。
三层以上 iframe 嵌套会直接触发性能断崖——不是变慢，而是加载延迟叠加 30–80ms、内存陡增、postMessage 断链、iOS Safari 中 contentWindow 为 null 或 onload 丢失。控制数量不是“建议”，而是必须卡死的硬边界。
怎么快速确认当前嵌套是否已超限
别手动数 <iframe></iframe> 标签，DOM 结构 ≠ 运行时嵌套深度。真正要测的是 contentWindow 链：
- 在浏览器 Console 执行：
function getIframeDepth(el = document.body) { const iframes = el.querySelectorAll('iframe'); let max = 0; iframes.forEach(iframe => { try{ if(iframe.contentDocument) { max = Math.max(max, 1 + getIframeDepth(iframe.contentDocument.body)); } }catch(e) {} }); return max; } getIframeDepth(); - 返回值 ≥ 3 就得立即干预；返回 0 不代表安全，可能是全跨域或尚未加载完成
- Vue/React 中动态生成的 iframe（如
v-if或useState触发）需等mounted/useEffect后再运行该函数
为什么不能靠 “只用两层” 来设计架构
表面看两层很安全，但实际部署中极易突破：主应用（1）→ 微前端子应用（2）→ 子应用内又嵌了监控 SDK 或广告 iframe（3+），这种隐式叠加极难察觉。
- 检查
document.querySelectorAll('iframe').length，若 ≥ 3 且多个src指向同一域名下的子系统，风险极高 - 用 Chrome DevTools 的 Performance 面板录制加载过程，观察 “Renderer Process” 是否出现多个持续高占用长条（每个对应一个 iframe）
- Memory 面板拍快照后展开 “Detached DOM tree”，若大量节点标为 “iframe document” 且无法被 GC 回收，说明销毁逻辑缺失，已埋下内存泄漏
销毁 iframe 时最常漏掉的三件事
iframe.remove() 只删 DOM，不等于释放 JS 上下文——子页面里还在跑的代码会继续吃内存。
立即学习“前端免费学习笔记（深入）”；
- 未清除
setInterval或setTimeout：尤其 React/Vue 子应用中，useEffect或mounted启动的定时器，若 unmount 未触发或没清理，会持续持有window引用 - 未解绑全局
message监听器：父页写window.addEventListener('message', handler)，却忘了配对removeEventListener，导致子 iframe 的contentWindow无法被回收 -
console.log在子 iframe 中高频输出：V8 会保留日志引用链，实测 100 条未清空日志可让内存驻留增加 8–12MB
微前端场景下，“顶层”不等于 window.top
在 qiankun、icestark 等微前端框架中，主应用作为容器加载子应用，此时业务意义上的“顶层”是主应用所在的 window 实例，而非浏览器最外层的 window.top。
- 盲目用
window.top.postMessage可能发到错误上下文，尤其当页面本身已被嵌入其他平台（如钉钉、飞书）时 - 应由主应用暴露统一通信入口（如
window.__MICRO_APP），子应用通过它中转消息，避免逐层遍历parent - 慎用
sandbox="allow-top-navigation"：Chrome 98+ 会静默忽略window.top.location.href =赋值，且无控制台报错，排查成本极高
嵌套层级不是配置项，是运行时状态；它藏在 contentWindow 链里，而不是 HTML 缩进里。每次新增 iframe，都得同步评估其子页面是否自带嵌套、是否含第三方 SDK、是否会在销毁时残留 JS 上下文——这些点漏掉任何一个，都可能让“两层”变成事实上的四层。
