iframe 本身不导致内存溢出，真正原因是未销毁的 contentwindow 及其 js 引用链；频繁创建/销毁、嵌套或加载重型资源时泄漏加剧，需在 remove() 前设 src="javascript:false" 并清空所有引用。
iframe 本身不会直接导致内存溢出，真正触发溢出的是**未被正确销毁的 iframe 执行上下文及其持有的 JS 引用链**——尤其在频繁创建/销毁、嵌套使用或加载重型资源（如地图 SDK）时，泄漏会快速累积到临界点。
为什么 iframe.contentWindow 不释放就等于内存钉子
只要父页面还持有 iframe.contentWindow 的引用（哪怕只是缓存在 this.iframeWin 或全局变量里），浏览器就无法回收该 iframe 内部的整个文档对象、JS 堆、事件监听器和定时器。即使你调用了 iframe.remove()，contentWindow 仍可能存活，表现为 DevTools Memory 面板中持续增长的 Detached HTMLDocument 实例。
- 常见错误：在 React/Vue 组件中把
iframe.contentWindow存为实例属性，但useEffect或beforeUnmount里只删 DOM，没置空引用 - 验证方式：拍两个堆快照，筛选
Detached HTMLDocument，若数量随“打开-关闭”线性增加，且 Retainers 显示Closure → function → iframeWin，就是它 - IE/Edge Legacy 更严重：设
src = ""或src = "about:blank"并不真正卸载 JS 上下文，残留的地图脚本、统计代码可能长期驻留
iframe.src = 'javascript:false' 比 about:blank 更有效
在 IE 和旧版 Edge 中，src = "about:blank" 仍会保留部分文档状态；而 src = "javascript:false" 是一种强制清空机制，它等效于执行 document.open(); document.close();，能更可靠地触发多数第三方 SDK（如百度地图 v2.x）内部的 destroy 流程。
- 必须在
remove()之前设置，否则清理逻辑跳过 - 不要用
innerHTML = ""或display: none替代——它们完全不触发卸载 - Chrome/Firefox 下也建议统一使用，避免跨浏览器行为差异
多重嵌套 iframe 会让内存压力指数级放大
每层 iframe 都需独立 renderer 进程（Chromium）、完整 JS 引擎初始化、CSSOM 构建，且父子 window 间通信只能靠 postMessage 序列化，无法共享引用。实测 3 层嵌套在 Android 低端机上即可让内存占用飙升 50%+，并触发白屏或进程回收。
- 识别方式：DevTools Elements 面板搜
<iframe></iframe>，看是否出现连续嵌套；或执行document.querySelectorAll('iframe').length ≥ 3 - 子 iframe 中未清除的
setInterval、高频console.log、未解绑的window.addEventListener('message', handler)都会阻止 GC - 跨域 iframe 尤其危险：父页监听
message时若用匿名函数注册，就无法配对removeEventListener，闭包会永久持有contentWindow
最隐蔽的问题往往不在 iframe 创建时，而在销毁路径上——比如忘了清掉定时器、漏掉 removeEventListener、或者以为 remove() 就万事大吉。真实项目里，一个没被注销的 postMessage 监听器，就能让几 MB 内存永远卡在 Detached 状态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
