javascript内存泄漏源于意外强引用链导致对象不可被gc回收，常见于全局变量持有、未移除事件监听器、未清理定时器、闭包捕获大对象及dom节点与监听器组合未解绑。
JavaScript 中的内存泄漏不是“变量没被 delete”或“对象没被手动回收”这么简单——V8 引擎会自动垃圾回收，但只要存在**意外的强引用链**，对象就无法被回收，内存就会持续增长。
哪些引用会导致对象无法被 GC 回收
垃圾回收器（GC）只清除那些“不可达”的对象。所谓“不可达”，是指从根对象（如 globalThis、当前执行上下文的变量环境等）出发，没有任何一条引用路径能访问到它。以下情况会让对象意外保持可达：
- 全局变量意外持有 DOM 节点或大型数据结构（例如
window.cache = largeArray） - 事件监听器未移除，且回调中闭包捕获了外部大对象（
element.addEventListener('click', () => console.log(bigData))，之后未调用removeEventListener） - 定时器（
setInterval/setTimeout）的回调长期存活，并引用着本该销毁的组件实例 - 闭包中保留对父作用域中大数组、大 Map 或 DOM 节点的引用，而该闭包又被全局或长生命周期对象持有
DOM 节点 + 事件监听器是最常见的泄漏组合
尤其在单页应用中，组件卸载（unmount）后如果忘了清理，极易泄漏。比如 React 中未用 useEffect 清理，或原生 JS 中动态创建元素后未解绑：
// ❌ 危险：节点被移除，但监听器仍活着，且闭包里有 data
const data = new Array(10000).fill('payload');
const btn = document.createElement('button');
btn.addEventListener('click', () => console.log(data));
document.body.appendChild(btn);
// ... 后续 btn 被 remove()，但 data 仍被监听器闭包引用
✅ 正确做法是显式清理：
立即学习“Java免费学习笔记（深入）”；
const handler = () => console.log(data);
btn.addEventListener('click', handler);
// 卸载时：
btn.removeEventListener('click', handler);
// 或使用 AbortController（现代推荐）：
const ac = new AbortController();
btn.addEventListener('click', () => console.log(data), { signal: ac.signal });
// 卸载时：
ac.abort(); // 自动移除所有绑定 signal 的监听器
用 Chrome DevTools 快速定位泄漏点
不要靠猜。打开 Memory 面板，用“堆快照（Heap Snapshot）”对比操作前后的差异：
- 先拍一张快照（Take heap snapshot），做一次操作（如打开/关闭模态框）
- 再拍一张，切换到
Comparison视图，筛选Retained Size大幅增加的对象 - 重点关注
Closure、HTMLDivElement、Array等类型，点开看 “Retainers” 列——谁在引用它？是不是某个没清理的eventListener或全局Map？ - 特别注意
(system)类型下的Detached DOM tree：说明 DOM 节点已被移除，但 JS 仍有引用，典型泄漏信号
真正难排查的从来不是“有没有泄漏”，而是“谁在悄悄留着引用”。哪怕只多持有一个 1MB 的 ArrayBuffer，挂载 20 次组件就吃掉 20MB——用户不重启浏览器，这部分内存就不会还给系统。
