JavaScript中最常见内存泄漏场景是DOM元素移除后事件监听器或闭包仍持有引用；需及时清理addEventListener、定时器、全局变量及跨模块引用链。
监听事件没清理，闭包引用没断开，内存就涨上去了
JavaScript 中最常见内存泄漏场景就是 DOM 元素被移除后，其绑定的事件监听器或闭包中仍持有对它的引用。浏览器无法回收该元素及其关联对象，导致内存持续增长。
-
addEventListener后忘记调用removeEventListener（尤其在单页应用组件卸载时） - 使用匿名函数作为监听器，导致无法精确移除：
el.addEventListener('click', () => {...})→ 换成具名函数或用AbortController方式管理 - 闭包中意外捕获了大型 DOM 对象或全局变量，比如在定时器回调里长期持有
document.getElementById('huge-list')的引用 - Vue/React 组件中，
useEffect或mounted里启动了定时器、WebSocket、IntersectionObserver，但unmounted/useEffect cleanup没正确关闭
setTimeout 和 setInterval 不清理，会拖垮整个页面
定时器回调函数会形成闭包，若其中引用了外部作用域的大对象（如整个 data 数组、ref 实例），且定时器未清除，这些对象就一直无法 GC。
- 始终保存定时器 ID，并在不需要时调用
clearTimeout或clearInterval - 避免在循环中反复
setInterval而不清理旧的 —— 常见于轮询逻辑写错，造成多个同功能定时器并存 - 用
requestIdleCallback替代高频setTimeout(fn, 0)，减少主线程争抢 - 注意：Node.js 环境下
setInterval不自动销毁，进程退出前必须手动clearInterval，否则可能阻止进程退出
全局变量和意外挂载是“静默泄漏”高发区
显式声明 var foo = {} 在函数外，或隐式创建（如直接赋值 foo = {}），都会让对象挂在 window（浏览器）或 global（Node）上，生命周期与页面/进程一致，基本不会被回收。
- 检查控制台是否出现
ReferenceError: xxx is not defined之后又莫名能访问到该变量 —— 很可能是隐式挂载 - Webpack/Vite 构建产物中慎用
this指向window的代码；ESM 模块默认严格模式，但某些动态eval或with语句仍可能导致意外泄露 - 第三方 SDK 初始化时有时会往
window上挂工具对象（如window.SDKHelper），若你又把它传进长生命周期闭包，就得手动解绑
Chrome DevTools 怎么确认是不是真泄漏了
光看内存占用数字没用，得看“增长是否可复现 + 是否随操作释放”。关键不是峰值，而是重复操作后堆内存是否阶梯上升。
立即学习“Java免费学习笔记（深入）”；
- 打开 Memory 面板 → 点击 Record allocation timeline → 执行一次操作（如打开弹窗 → 关闭）→ 停止录制 → 查看蓝色条（新分配对象）是否在关闭后仍大量存活
- 用 Heap snapshot 对比：操作前拍一张，操作后（等待几秒触发 GC）再拍一张 → Comparison 视图下筛选
Detached DOM tree，数量不为 0 就说明有 DOM 泄漏 - 重点关注
Closure类型对象的保留路径（Retaining path），它会明确告诉你哪个闭包、哪行代码持有了不该持有的引用 - 注意：V8 的 GC 是分代+增量的，刚移除元素不代表立刻释放 —— 等 1–2 秒再拍快照更准
function setupAutoRefresh(el) {
let timerId;
const update = () => {
el.textContent = Date.now();
};
timerId = setInterval(update, 1000);
// 必须暴露清理方法
return () => clearInterval(timerId);
}
// 使用示例
const cleanup = setupAutoRefresh(document.getElementById('clock'));
// 页面离开前调用
cleanup();
真正难处理的是跨模块引用链：比如 A 模块注册监听，B 模块触发事件，C 模块在回调里缓存数据 —— 这种泄漏要靠 consistently 清理策略，而不是某一行代码改掉就能解决。 
