target="_blank" 会通过 window.opener 建立双向引用，导致原页面 window 被新页面意外持有而无法释放；用 memory 面板拍快照后筛选 window 并查看 retainers 中是否含 opener 字段即可确认，且需在关闭新 tab 后拍快照对比数量是否回落。
为什么 target="_blank" 会间接引发内存泄漏？
它本身不泄漏内存，但会让新页面和原页面通过 window.opener 维持双向引用。如果新页面 JS 复杂、长期运行（比如监控型 SPA 或埋点 SDK），它的 DOM、闭包、定时器就可能意外持有对原页面 window 或其子对象的引用——而原页面又无法主动释放这个“远端引用”。Chrome DevTools 的堆快照里常看到 Window 实例被 opener 字段 retain，且生命周期远超预期。
如何用 Chrome DevTools 快速确认是否是 opener 引起的泄漏？
打开 Memory 面板 → 拍摄堆快照（Heap snapshot）→ 在筛选框输入 Window → 展开任意一个疑似“不该存在”的 Window 实例 → 点击右侧的 “Retainers” 标签 → 查看引用链中是否出现 opener 字段或 Window.opener 路径。若存在，且该 Window 对应的是你已关闭的 tab（但快照里仍存活），基本可锁定问题源头。
- 务必在点击
target="_blank"链接后、再关闭新 tab、最后拍快照，否则引用链可能已被 GC 清理 - 对比两次快照：第一次在打开新 tab 后立即拍，第二次在关闭新 tab 后再拍；观察
Window数量是否未回落 - 注意排除 Service Worker 或 iframe 导致的类似 retain，重点看
opener是否指向当前 tab 的window
rel="noopener" 是不是万能解药？
不是。它只切断 window.opener 引用，但无法解决以下情况：
- 新页面 JS 主动调用
opener.postMessage()并在原页面监听了message事件，却忘了removeEventListener - 原页面通过
beforeunload监听器向 opener 发送清理信号，但新页面没响应，导致监听器一直挂载 - 使用
window.open()手动打开窗口，却没显式设newWin.opener = null，即使加了rel="noopener"也无效（因为该属性只作用于<a></a>标签）
所以加 rel="noopener" 是必要条件，不是充分条件。真正要防泄漏，得让两个页面彼此“不认识”，也不“打招呼”。
自动化测试中多标签页场景怎么避免误判？
SeleniumBase 或 Playwright 测试脚本频繁开关 tab 时，window_handles 滞后或句柄残留极易造成假阳性泄漏报告。关键动作不是“关掉 tab”，而是“销毁 Page 实例”：
- Playwright：调用
page.close()后，确保不再访问该page对象；BrowserContext 关闭前，所有Page必须已 close - SeleniumBase：不要只靠
driver.close()，需配合driver.switch_to.window(original_handle)再driver.close()，否则 driver 可能仍绑定在已销毁的上下文上 - 任何框架下，避免在
page.on('close', ...)回调里继续操作该 page —— 它已处于销毁中状态
真实泄漏往往藏在“页面已关，但引用还在”的缝隙里，而不是 tab 列表里多了一个 handle。
