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 怎么确认是不是真泄漏了

光看内存占用数字没用，得看“增长是否可复现 + 是否随操作释放”。关键不是峰值，而是重复操作后堆内存是否阶梯上升。

• 打开 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();