JavaScript内存泄漏本质是本该释放的对象仍被引用，导致GC无法回收；主因包括意外全局变量、未清理事件监听器与定时器、闭包不当引用及DOM引用未释放。
JS 内存泄漏不是代码写得“不规范”那么简单，而是引用关系没理清、生命周期没对齐、自动回收机制被无意绕过的结果。防坑核心就四点：别让对象意外挂住、别让监听器长期驻留、别让闭包拖着大块内存、别让定时器在后台空转。
防止全局变量意外驻留
未声明的变量会自动挂到 window（浏览器）或 global（Node），变成全生命周期存活的“钉子户”。哪怕只存一个大数组，也会一直占着堆内存不放。
- 始终启用 'use strict'，避免隐式全局
- 用 let/const 替代 var，限制作用域
- 模块化开发中，导出只暴露必要接口，避免把内部大对象通过 module.exports 暴露出去
- 调试时慎用 console.log(obj) 打印大型对象——某些浏览器控制台会保留引用，阻碍回收
清理事件监听与 DOM 引用
DOM 元素被移除后，若 JS 仍持有它的引用，或它身上还绑着监听器，这个节点及其关联数据就无法被 GC 回收。尤其常见于动态渲染的列表、弹窗、图表容器。
- 手动移除节点前，先调用 element.removeEventListener；或统一用事件委托，监听父级，靠 event.target.matches 判断来源
- 使用 el.remove() 而非 parent.removeChild(el)，现代浏览器中前者会自动剥离内置监听器
- 组件销毁时（如 React useEffect cleanup、Vue beforeUnmount），必须显式清理：解绑事件、清空定时器、置空缓存的 DOM 引用
- 长期管理 DOM 的类（如表格控制器），销毁方法里要主动执行 this.$el = null 或清空引用字段
管控闭包与定时器生命周期
闭包本身不是问题，问题在于它悄悄把外部变量“锁住”了；定时器也不是问题，问题在于回调函数活着，它引用的所有东西都跟着活。
- 避免在闭包中直接捕获大型对象（如 bigData、canvas.getContext），只取需要的字段或浅拷贝
- 定时器必须配对清除：setInterval 对应 clearInterval，setTimeout 对应 clearTimeout，且清理逻辑要写在卸载路径中
- 不要在循环中反复创建新定时器却不存 id —— 这等于放任无数个回调长期驻留内存
- 高频回调（如 scroll、resize）务必节流 + 清理，避免回调函数形成闭包链并持续引用上下文
借助工具定位与验证
靠肉眼很难发现泄漏，得用工具建立可观测性：
- Chrome DevTools → Memory 面板，录制堆快照（Heap Snapshot），对比多次操作后的“Detached DOM tree”数量和大小
- 使用 Allocation instrumentation on timeline 记录内存分配，观察是否有某类对象持续增长
- 在关键路径（如弹窗打开/关闭、页面切换）前后手动触发垃圾回收（Collect garbage按钮），看内存是否回落
- 生产环境可注入轻量监控：定期记录 performance.memory.usedJSHeapSize（如有），设置阈值告警
