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); - 使用
AbortController配合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 树一层层往上翻。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
