跨域 iframe 通信本身不导致内存泄漏，但未清理事件监听器、event.source 强引用、定时器及 pending 请求会引发内存持续增长；需在卸载前主动移除监听、弱化引用、清除异步任务并协同子页完成销毁流程。
跨域 iframe 通信本身不直接导致数据驻留或内存泄漏，但不当的事件监听、闭包引用和未释放的消息通道会引发内存持续增长。关键不在“通信”而在“清理”——多数问题源于开发者忘了关掉监听器、没解绑回调、或让数据意外被全局变量长期持有。
避免 message 事件监听器堆积
每次调用 window.addEventListener('message', handler) 都会新增一个监听器。若在 iframe 重载、组件销毁时未移除，旧监听器仍驻留在内存中，持续响应新消息，造成重复执行与内存滞留。
- 始终使用具名函数（而非匿名函数），便于后续移除：
function handleMessage(event) { /* 处理逻辑 */ }window.addEventListener('message', handleMessage); - 在 iframe 卸载或父组件销毁前，主动清理：
window.removeEventListener('message', handleMessage); - 若使用 Vue/React 等框架，在
onUnmounted或useEffect cleanup中统一处理
防止 event.source 引用阻断垃圾回收
在 message 回调中，event.source 是对发送方 window 的强引用。若将它缓存到全局对象、闭包变量或未清理的 Map 中（例如用于后续回传），会导致整个 iframe 窗口对象无法被 GC 回收，尤其在 iframe 频繁创建销毁的场景（如微前端子应用切换）下尤为明显。
- 避免长期保存
event.source；如需回传，建议每次用event.source.postMessage(...)即用即发 - 若必须缓存，使用
WeakMap关联 source 和临时状态，并在 iframeunload事件中清空对应项 - 不要把
event.source赋值给window、globalThis或模块级变量
清理定时器与异步 pending 状态
跨域通信常伴随超时控制、重试逻辑或 Promise 缓存（例如防重复请求）。若 iframe 已卸载，但定时器仍在运行，或 Promise 的 resolve/reject 回调中持有 DOM 引用，就会造成内存驻留。
- 所有
setTimeout/setInterval需配套clearTimeout/clearInterval，并在销毁时调用 - 对每个发出的 postMessage 请求，维护唯一 ID 并在收到响应后从 pending Map 中删除；未响应的请求应在合理超时后主动清理
- 避免在 Promise 回调中操作已移除的 DOM 元素（可用
if (el.isConnected)判断）
iframe 重载/替换时的主动重置
用 iframe.src = '' 或重新设置 src 替换 iframe 内容时，旧页面不会自动触发 unload，其 JS 上下文可能残留。应主动通知子页准备卸载，并等待确认后再加载新内容。
- 父页发送退出指令：
iframe.contentWindow.postMessage({ type: 'DISPOSE' }, targetOrigin); - 子页监听并执行清理逻辑（移除监听器、清除定时器、释放资源），再回传确认
- 父页收到确认后，再执行
iframe.src = newUrl或iframe.remove()
