JavaScript内存泄漏主因有四：全局变量意*载、事件监听器未解绑、闭包保留大对象或DOM引用、定时器未清除；需用严格模式、ESLint、AbortController、堆快照等工具定位并清理。

全局变量意*载导致内存无法释放

JavaScript 中未声明的变量会自动成为 window（浏览器）或 global（Node.js）的属性，长期持有对象引用就等于锁住内存。比如在函数里写 user = { name: 'Alice' } 而不是 let user = { name: 'Alice' }，这个对象就永远活在全局作用域里。

• 检查所有未加 let/const/var 的赋值语句
• 开启严格模式（'use strict'），让这类错误直接报 ReferenceError
• 用 ESLint 规则 no-implicit-globals 或 no-unused-vars 提前拦截

事件监听器未解绑（尤其是 DOM 和自定义事件）

给元素绑定 addEventListener 后，如果组件卸载、页面跳转或 DOM 被移除，但没调用 removeEventListener，回调函数及其闭包捕获的变量就会持续驻留内存。React/Vue 等框架内部处理了部分情况，但手动操作 DOM 时极易遗漏。

• 始终保存监听器函数的引用（不能传匿名函数），方便后续解绑：const handler = () => {...}; el.addEventListener('click', handler); el.removeEventListener('click', handler);
• 使用 AbortContro

  

  ller 配合 addEventListener 的 signal 选项（现代浏览器支持），销毁时调用 controller.abort() 即可批量清理
• 对长期存在的事件总线（如 EventEmitter），确保订阅者在生命周期结束时调用 off 或 removeListener

闭包中保留大对象或 DOM 引用

闭包本身不是问题，但当内部函数被意外保留在长生命周期对象（如定时器、全局缓存、未清除的 Promise 回调）中，并捕获了大型数据结构或 DOM 元素，就会阻止垃圾回收。

• 避免在定时器回调中直接引用外部大数组或整个 document.body；改用 ID 或轻量标识符，需要时再查
• 不要把 DOM 元素作为闭包参数传进长期存活的函数，尤其在单页应用路由切换后仍可能被引用
• 用 Chrome DevTools 的 Memory > Take heap snapshot 对比前后快照，筛选 Closure 类型，看哪些变量名下挂了不该有的 DOM 或大型对象

定时器未清除（setInterval / setTimeout）

setInterval 是最典型的“隐形内存锚点”：只要定时器 ID 还有效，其回调函数和闭包内所有变量就无法被回收，哪怕对应的 UI 已经消失。常见于轮询接口、动画帧控制、状态同步等场景。

• 每次创建定时器都要保存返回值（const timerId = setInterval(...)），并在合适时机调用 clearInterval(timerId)
• 在组件卸载、页面隐藏（visibilitychange）、或数据流终止时主动清理，不要依赖用户关闭标签页
• 避免在闭包中反复 setInterval 却不先 clearInterval —— 这会产生多个并行定时器，且旧的仍活着

真正难排查的是那些跨模块、跨生命周期的隐式引用链，比如一个被 Promise 缓存的响应数据，又被某个未注销的 WebSocket 回调引用，再通过事件总线转发到已销毁的 React 组件里。这种时候光看代码逻辑很难发现，必须结合堆快照里的 retainers 树一层层往上翻。