javascript内存泄漏是对象该被回收却因未清理引用而持续滞留，导致内存悄悄上涨、页面变卡；防范关键在于编码时建立引用生命周期意识——谁创建谁清理，包括事件监听器配对解绑、定时器显式清除、禁用隐式全局变量、dom移除前断开js引用、闭包精简捕获并及时置null。
JavaScript 内存泄漏不是代码报错，而是对象该被回收却一直被“拴住”，内存悄悄上涨，页面越用越卡。防范关键不在事后排查，而在编码时建立明确的引用生命周期意识——谁创建，谁清理。
事件监听器必须配对解绑
DOM 元素移除后，若事件回调还挂在上面，整个闭包作用域都会滞留。尤其在单页应用中，组件反复挂载/卸载时极易遗漏。
- 绑定时保存回调函数引用，确保能精确 removeEventListener；不要用匿名函数直接绑定
- React 中在 useEffect 清理函数里解绑；Vue 中在 onBeforeUnmount 或 beforeDestroy 里处理
- 对只触发一次的操作，直接使用
{ once: true }选项，省去手动管理
定时器要显式清除
setInterval 或 setTimeout 的回调若捕获了外部大对象（比如缓存数据、Canvas 上下文），而定时器本身没被清除，这个对象就永远无法释放。
- 声明定时器时务必保存 ID（如
const timer = setInterval(...)） - 在组件销毁、路由离开或逻辑结束时，调用
clearInterval(timer)或clearTimeout(timer) - 避免在闭包中长期持有定时器 ID；必要时设为
null防止重复清除
杜绝意外全局变量
非严格模式下漏写 let/const，比如 data = new Array(1e6)，会自动挂到 window 下，直到页面关闭才释放——这是最隐蔽也最容易修复的泄漏源。
- 所有脚本顶部加
"use strict"，让隐式全局直接报错 - 启用 ESLint 规则
no-implicit-globals和no-undef - 编辑器开启实时提示，把裸赋值当高亮警告处理
DOM 引用和闭包要主动断开
节点已从文档中移除（el.remove() 或 innerHTML = ''），但 JS 还拿着它（比如存进数组、Map 或闭包里），它就成了“分离的 DOM 树”——看不见，却占着全部样式、事件和子树内存。
- 移除 DOM 前，先清空所有 JS 对它的引用：
cacheList = cacheList.filter(item => item !== el) - 关联 DOM 数据时，优先用
WeakMap（键是 DOM 节点，节点销毁后自动清理） - 闭包只捕获真正需要的变量；不再需要时，手动将引用设为
null
不复杂但容易忽略：每次添加异步资源（定时器、监听器、Observer、fetch AbortController），都同步写好对应的清理逻辑。养成习惯，比靠 DevTools 事后救火高效得多。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
