内存泄漏是本该被回收的内存因被意外持有而持续增长，表现为页面变卡、堆内存持续上升；常见原因包括未清除定时器、未移除事件监听器、闭包持有大对象及跨模块隐式引用。
什么是内存泄漏：JavaScript 中的“忘了删”
内存泄漏不是程序崩溃，而是本该被回收的内存一直被意外持有，导致占用持续增长。JavaScript 有自动垃圾回收（GC），但 GC 只能清理“不可达对象”——如果某个对象仍被某个活跃作用域、全局变量、闭包或事件监听器间接引用，它就永远不会被释放。
常见现象包括：页面长时间运行后变卡、堆内存使用量在 Chrome DevTools 的 Memory 面板中持续爬升、performance.memory.usedJSHeapSize 不断增大且不回落。
定时器未清除：最隐蔽的泄漏源
setInterval 和 setTimeout 的回调函数会形成闭包，若回调中引用了外部大对象（比如 DOM 节点、大型数组），而定时器本身又没被 clearInterval 或 clearTimeout 清理，这个引用链就一直存在。
- 组件卸载（如 React
useEffect清理、VuebeforeUnmount）时必须手动清除定时器 - 避免在定时器回调中直接访问
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 节点残留 + 监听器闭包持有了外部作用域变量。
立即学习“Java免费学习笔记（深入）”；
- 永远不用匿名函数绑定需要手动移除的监听器：
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 引用——这时泄漏源头不在工具函数，而在调用方没清理引用。
