17370845950

内存泄漏是本该被回收的内存因被意外持有而持续增长，表现为页面变卡、堆内存持续上升；常见原因包括未清除定时器、未移除事件监听器、闭包持有大对象及跨模块隐式引用。

什么是内存泄漏：JavaScript 中的“忘了删”

内存泄漏不是程序崩溃，而是本该被回收的内存一直被意外持有，导致占用持续增长。JavaScript 有自动垃圾回收（GC），但 GC 只能清理“不可达对象”——如果某个对象仍被某个活跃作用域、全局变量、闭包或事件监听器间接引用，它就永远不会被释放。

常见现象包括：页面长时间运行后变卡、堆内存使用量在 Chrome DevTools 的 Memory 面板中持续爬升、performance.memory.usedJSHeapSize 不断增大且不回落。

定时器未清除：最隐蔽的泄漏源

setInterval 和 setTimeout 的回调函数会形成闭包，若回调中引用了外部大对象（比如 DOM 节点、大型数组），而定时器本身又没被 clearInterval 或 clearTimeout 清理，这个引用链就一直存在。

• 组件卸载（如 React useEffect 清理、Vue beforeUnmount）时必须手动清除定时器
• 避免在定时器回调中直接访问 this 或组件实例，改用弱引用或提前解构所需字段
• 不要把定时器 ID 存在全局变量或长生命周期对象上，除非你明确控制其销毁时机

let timerId;
function start() {
  const largeData = new Array(100000).fill('data');
  timerId = setInterval(() => {
    console.log(largeData.length); // 引用了 largeData → 它无法被 GC
  }, 1000);
}
// 必须配对调用：
function stop() {
  clearInterval(timerId);
  timerId = null; // 防止悬挂引用
}

事件监听器没移除：DOM + 闭包双重陷阱

给 DOM 元素绑定 addEventListener 后，若元素被移除但监听器未用 removeEventListener 解绑，且监听器是匿名函数或闭包，就极易泄漏——DOM 节点残留 + 监听器闭包持有了外部作用域变量。

• 永远不用匿名函数绑定需要手动移除的监听器：el.addEventListener('click', () => {...}) → 无法精确移除
• 优先使用 AbortController（现代方案）：el.addEventListener('click', handler, { signal })，销毁时调用 controller.abort()
• 在单页应用中，路由跳转或组件销毁时，确保清理所有手动添加的监听器

const controller = new AbortController();
document.body.addEventListener('scroll', () => {
  console.log('scrolled');
}, { signal: controller.signal });

// 销毁时只需：
controller.abort(); // 自动移除所有关联监听器

闭包持有大对象：你以为它小，其实它很重

闭包本身不泄漏，但若内部函数长期存活（如被挂到全局、存进缓存、传给异步 API），而它又捕获了本不该长期持有的大对象（document.body、JSON.parse(bigJson) 结果、Canvas 上下文等），就会让这些对象无法释放。

• 检查函数是否真的需要访问外层全部变量；只解构必要字段，避免直接引用整个对象
• 对缓存类逻辑，用 WeakMap 替代普通 Map 存储实例相关数据，它不会阻止键对象被回收
• 避免在构造函数或初始化逻辑中，把 this 传给定时器、事件监听器或 Promise 回调，除非你确定生命周期一致

真正难排查的是跨模块隐式引用：比如一个工具函数接收了某个 Vue 实例并缓存起来，而该实例又持有大量模板数据和 DOM 引用——这时泄漏源头不在工具函数，而在调用方没清理引用。