JavaScript垃圾回收基于可达性，非手动delete/null；内存泄漏主因是本该断开的引用仍存在。常见于未清理定时器、事件监听器或闭包持有大对象。定位用Chrome内存快照对比Retainers链路。
JavaScript 的垃圾回收不靠你手动 delete 或 null，而是看一个对象“还能不能被找到”——从全局变量、当前函数变量这些“根”出发，顺着引用链能触达的，就留下；触达不到的，下次 GC 时就被清掉。所以内存泄漏的本质从来不是“忘了清理”，而是“本该断开的引用，还牢牢焊在那儿”。
为什么 obj = null 有时没用？
赋值 null 只是断开了当前这一个变量的引用，如果还有别的地方（比如闭包、事件监听器、缓存 Map）持有着它，对象照样活得好好的。GC 不认“你主观认为它该死了”，只认“有没有路能走到它”。
- 常见错误现象：页面跳转后内存不降，
performance.memory.usedJSHeapSize持续上涨 - 典型场景：React Class 组件里
componentDidMount启动了setInterval，但componentWillUnmount没调clearInterval，回调里的this就卡住了整个组件实例 - 实操建议：不要依赖
null保平安；优先在销毁时机显式清理源头——removeEventListener、clearTimeout、AbortController.abort()
哪些闭包会悄悄锁住整棵树？
闭包本身合法，但它会完整保留外层函数的词法环境。如果你在循环里给每个 DOM 元素绑事件，而回调里用了 dataList（一个 10MB 的数组），那哪怕只点了一个按钮，整个 dataList 都无法释放。
- 常见错误现象：“Detached DOM tree” 在 Chrome Memory 面板中反复出现，且 Retained Size 很大
- 使用场景：为列表项绑定点击事件、封装工具函数时缓存配置、React 中 useCallback 依赖项写错
- 实操建议：
– 只捕获真正需要的值，比如用item.id替代item
– 大对象用完后主动设largeData = null（比[]更明确）
– 关联元数据优先用WeakMap，例如const tooltipCache = new WeakMap()，键是 DOM 节点，不怕节点被移除后残留
怎么用 Chrome DevTools 快速定位泄漏点？
别猜，直接拍快照对比。重点不是看“哪个对象多”，而是看“哪个对象在操作后持续增长，且被谁拽着不放”。
立即学习“Java免费学习笔记（深入）”；
- 操作路径：打开 Chrome DevTools → Memory 面板 → 点击
Take Heap Snapshot→ 执行疑似泄漏的操作（如打开/关闭弹窗）→ 再拍一张 → 左侧选中第二张快照 → 上方 Filter 输入Constructor，筛选Array、Object或你的类名 → 点开某行 → 右侧看Retainers链路 - 关键信号：
(closure)下挂着不该有的大数组、window下多出未声明变量、EventListener指向已移除的 DOM 节点 - 注意坑：Heap Snapshot 是静态快照，抓不到正在运行的定时器；若怀疑异步持有，配合
Allocation instrumentation on timeline录制更准
最常被忽略的一点：WeakMap 和 WeakRef 不是“防泄漏银弹”，它们只是不阻碍回收——如果那个对象本身还被其他强引用拖着，WeakMap 也救不了它。真正要做的，是在设计阶段就问一句：这个引用，是不是非得一直活着？
