javascript内存泄漏本质是该回收的对象未被回收，主因是引用关系未断干净，包括未清理事件监听器、闭包意外保留大对象、定时器未清除、全局变量泄漏等。
JavaScript内存泄漏不会立刻报错，但会导致页面越来越卡、标签页崩溃、DevTools里内存曲线持续爬升——它本质是“该回收的对象没被回收”，而根本原因几乎都落在引用关系没断干净上。
未清理的事件监听器导致 DOM 无法释放
给元素绑定 addEventListener 后，如果组件卸载或 DOM 被移除，但监听器没手动 removeEventListener，这个监听函数会继续持有对 DOM 元素的强引用，阻止 GC 回收整个节点树。
- 常见于 Vue/React 组件挂载时添加全局事件（如
window.addEventListener('resize', handler)），却在beforeUnmount或useEffect cleanup里漏掉移除 - 动态插入的 DOM（如弹窗、图表容器）绑定监听后，仅靠
innerHTML = ''或removeChild不够——监听器还在内存里挂着 - 使用匿名函数绑定时无法精准移除：
el.addEventListener('click', () => {...})→ 改用具名函数或AbortController方案
闭包中意外保留大对象引用
闭包本身不是问题，问题在于它捕获了本不该长期持有的变量。比如在定时器回调或事件处理器里，闭包引用了一个体积很大的数据对象或 DOM 节点，而该闭包又被全局变量、定时器或未解绑的监听器持续持有。
- 典型错误：
function createHeavyHandler() { const bigData = new Array(100000).fill('x'); return () => console.log(bigData.length); }—— 返回的函数永远拖着bigData - 修复思路：只闭包真正需要的值，而非整个对象；或在不再需要时主动将闭包内引用置为
null - 注意：箭头函数自动捕获外层作用域，比普通函数更易“悄悄”带入大对象
setInterval / setTimeout 没清理，还拿着 DOM 或 this
setInterval 是前端内存泄漏高发区，尤其当回调里直接访问 this 或某个 DOM 元素时。即使元素已被 remove()，只要定时器还在跑，引用链就不断。
- 错误模式：
setInterval(() => this.updateUI(), 1000)在 Vue 实例销毁后仍执行，this无法释放 - 安全写法：把 timer ID 存为实例属性（如
this.timerId），并在生命周期钩子（beforeUnmount）中调用clearInterval(this.timerId) - 更健壮的做法：在定时器回调开头加存活检查，例如
if (!this.$el || !document.contains(this.$el)) { clearInterval(timerId); return; }
全局变量和 this 泄漏（尤其非严格模式）
忘记用 let/const 声明变量，或在非严格模式下调用函数时 this 指向 window，都会把变量挂到全局作用域，直到页面关闭才释放。
- 典型错误：
function init() { data = fetchData(); }→data成为window.data - 隐式挂载：
function legacyHandler() { this.cache = largeObj; }→ 非严格模式下this === window - 强制防御：
'use strict';开头，所有变量必须显式声明；避免裸调用函数（用箭头函数或bind控制this）
最常被忽略的是「引用链的终点」：你以为清掉了 A，但 B 还通过闭包、定时器、事件监听器或静态 Map 持有 A；而 B 又被 C 长期持有……这种多层间接引用，得靠 Chrome DevTools 的 Memory 面板录制堆快照对比才能揪出来。别只盯着单个 removeEventListener，要顺藤摸瓜看整条引用路径。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
