确认是第三方图表iframe内存泄露需用Chrome Memory面板拍对比快照，重点关注HTMLIFrameElement、Detached HTMLDocument、Closure等构造器实例是否随开关操作线性增长；销毁前必须先设src='javascript:false'再remove()，老版本图表SDK无destroy接口时需手动清理定时器、事件监听器、Observer及Canvas。
iframe 加载第三方图表后内存不释放，怎么确认是它的问题
别看浏览器任务管理器里内存数字涨了就归罪 iframe——那是噪音。真正要盯的是 Chrome DevTools 的 Memory 面板：反复打开/关闭含图表 iframe 的区域（比如切换 tab 或弹窗），每次操作后拍一张 Heap Snapshot，切到 Comparison 视图，重点筛这几类构造器：
-
HTMLIFrameElement实例数是否随操作次数线性增加 -
Detached HTMLDocument或Detached HTMLBodyElement持续堆积 -
Closure对象的Retainers里是否还挂着contentWindow、document或图表实例（如ECharts、Chart、Highcharts）
只要其中任一列稳定上升，基本就是图表 iframe 没清干净。
销毁 iframe 前必须执行 src = 'javascript:false'
直接 iframe.remove() 或设 src = '' 在 IE/Edge Legacy 和部分老版 Chrome 中，图表 SDK 的全局定时器、事件监听器、Canvas 上下文仍驻留内存。而 src = 'javascript:false' 是个被验证有效的 hack：它触发 iframe 内部 document.open(); document.close();，多数图表库（如 ECharts v4/v5、Chart.js v2/v3）会在此时自动调用内部 dispose() 或 destroy() 流程。
- 必须在
remove()之前执行，顺序不能颠倒 - 不能用
innerHTML = ''或display: none替代——DOM 节点还在，JS 堆照样涨 - 若图表是通过
srcdoc注入的静态 HTML，需先清空srcdoc再设src = 'javascript:false'
图表 SDK 不提供 destroy 接口时的兜底清理
有些老版本图表（比如 Highcharts v3、ECharts v2.2.7）压根没暴露销毁方法，仅靠 iframe 清理不够。此时得手动干预其运行时环境：
立即学习“前端免费学习笔记（深入）”；
- 在
iframe.contentWindow上主动调用clearInterval、clearTimeout，遍历所有已知 timer ID（如有缓存） - 移除所有绑定在
contentWindow或document上的addEventListener，尤其注意 resize、scroll、message - 若图表使用了
IntersectionObserver或MutationObserver，必须显式调用.disconnect() - 对 Canvas 元素，手动清除
getContext('2d').clearRect()并置空.width/.height（防内存引用）
这些操作必须在 src = 'javascript:false' 之后、remove() 之前完成；否则 contentWindow 已失效，调用会静默失败。
现代浏览器里 iframe 图表泄漏的隐藏源头
Chrome/Firefox/Safari 虽有更强 GC，但图表 iframe 泄漏常因父页面“多管闲事”：
- 父页缓存了
iframe.contentWindow引用（比如存在this.iframeWin变量），GC 无法回收整个 iframe 环境 - 用了
postMessage通信，但没在 iframe 卸载前调用window.removeEventListener('message', handler) - 图表加载时注入了第三方脚本（如埋点 SDK、A/B 测试工具），它们在 iframe 内自行注册全局监听或定时器，且无清理入口
- 父页 CSS 使用了
contain: strict或will-change，反而干扰 iframe 渲染上下文释放
最易被忽略的是：**图表初始化后，父页面仍通过 iframe.contentDocument.querySelector 频繁访问其 DOM**——这会隐式维持对 iframe document 的强引用，阻止 GC。
