Retainers树中出现“(global)→window→…”链路，表明对象被全局或window强引用而无法GC；需重点排查window.addEventListener等未清理的监听器及闭包隐式捕获问题。
怎么看 Retainers 里那个“（global）→ window → …”链路
堆快照中出现 (global) 开头的保留路径，基本等于直接告诉你：某个对象被全局作用域或 window（浏览器）/ globalThis（Node）强引用着，无法 GC。重点不是“它在哪”，而是“谁在 window 上挂了它”。常见模式是：匿名函数监听器 + window.addEventListener + 没清理，导致整个闭包环境（含组件实例、state、ref）全被钉死。
实操建议：
- 在 Heap Snapshot 的
Retainers面板中，右键点击目标对象 →Reveal in Summary view，快速定位到它所属的构造函数或模块路径 - 展开保留路径，逐层往上点，特别注意中间是否出现
window、document、globalThis或process这类顶层对象 - 如果路径里有
_events、eventHandlers、listener字样，大概率是 EventEmitter 或 DOM 事件系统在持有着它 - 若路径终点是
Window下某个属性名（比如myResizeHandler），说明代码里显式赋值过window.myResizeHandler = ...，要反查源码
为什么匿名函数监听器会让 Retainers 深度爆炸
匿名函数没有名字，也没法被 removeEventListener 精确移除；更麻烦的是，它会隐式捕获外层所有变量——哪怕只是 const api = useApi()，整个 hook 返回的对象、内部缓存、甚至父组件的 props 都会被拖进保留路径。Retainers 显示的深度可能达 10 层以上，但真正该删的，往往只是那一行 window.addEventListener('scroll', () => {...})。
实操建议：
- 把所有
addEventListener、on、once调用统一替换成具名函数或绑定后的函数变量，例如：const handleScroll = useCallback(() => {...}, [deps]) - 在 React 中，确保每个
useEffect的 cleanup 函数里成对调用removeEventListener，且传入的函数引用必须完全一致 - Node.js 场景下，避免
emitter.on('data', (chunk) => {...})，改用function onData(chunk) {...}; emitter.on('data', onData)，以便后续emitter.removeListener('data', onData)
如何从 Retainers 快速定位到具体哪一行 JS 绑定了监听器
Chrome DevTools 的 Retainers 不直接显示行号，但能通过构造函数名和上下文推断。比如路径里出现 home.js @345463，说明快照里这个对象来自 home.js 文件第 345463 字节位置（不是行号）；配合 Source 面板搜索关键词 addEventListener 或 .on(，再结合函数名（如 initScrollObserver）就能快速定位。
实操建议：
- 在 Memory 面板中选中目标对象后，点击右上角
Object标签页，看Constructor名 —— 如果是Function，说明是函数对象；如果是IntersectionObserver或ResizeObserver，说明是 observer 实例，要检查它的observe()和disconnect()是否配对 - 在 Sources 面板中，Ctrl+Shift+F 全局搜索
addEventListener、onresize、onload等高频监听关键词，按文件分组排查 - 如果路径里反复出现
client._events或stream._events，说明是 Node.js 的 EventEmitter 实例泄漏，用util.inspect(emitter, { showHidden: true })查看具体监听器数量和函数引用
对比快照时，“Objects allocated between A and B” 为什么比 Retainers 更准
Objects allocated between A and B 是 Allocation Instrumentation 录制后生成的视图，它只展示在两次操作之间新分配、且到快照 B 时尚未被回收的对象。这比单纯看 Retainers 更聚焦“正在长胖”的内存块，尤其适合识别持续增长的监听器闭包。Retainers 只告诉你“谁在拽着它”，而 Allocation 视图能告诉你“它是什么时候被拽住的”。
实操建议：
- 录制前先清空缓存、关闭无关标签页，执行一次干净的交互（比如打开某页面 → 滚动三次 → 点击切换 tab）
- 录制时间控制在 10–20 秒内，太长会导致噪音过多；重点观察
Function、Closure、HTMLDivElement（Detached）这几类对象的增长量 - 如果发现
Closure类型对象持续增长，且 Constructor 名含handle、on、callback，基本可锁定为未清理的监听器闭包 - 对比两个 Allocation 快照时，右键某构造函数 →
Show allocation stack trace，就能看到它是在哪行代码 new 出来的
真正难的不是找到 Retainers 链路，而是确认那个“持有者”是不是本该存在的——比如你故意把一个监听器挂到 window 上用于跨页面通信，那它就不该被回收。判断依据永远是业务逻辑，不是工具提示。
