内存泄漏是未被回收的内存持续占用导致性能缓慢下降。四大场景：未清理事件监听器、闭包持有大对象、意外全局变量、Detached DOM树；Chrome DevTools三步定位；预防关键在“谁创建，谁清理”。
内存泄漏不是报错，是“悄悄吃掉内存”
JavaScript内存泄漏指本该被垃圾回收（GC）释放的内存，因为某些引用未断开，一直被JS引擎认为“还有用”，结果越积越多——页面不报错，但会越来越卡、滚动变慢、切换标签页延迟，甚至触发浏览器自动杀进程。它不像ReferenceError那样立刻暴露，而是温水煮青蛙式的性能退化。
四大高频泄漏场景和对应解法
真实项目里，90%以上的泄漏来自这四类写法，每类都附带“一眼能认出”的错误模式和落地修复动作：
-
未清理的事件监听器：组件卸载了，但
addEventListener没配对调用removeEventListener；尤其在React的useEffect或Vue的onBeforeUnmount里漏写返回函数。✅ 解法：绑定时存回调引用，卸载时明确解绑；或直接用{ once: true }（适合只触发一次的场景）。 -
闭包持有大对象：比如一个定时器回调里缓存了
largeImageArray或canvasContext，而这个回调本身被全局变量或长生命周期对象（如单例服务）持续引用。✅ 解法：不用闭包长期持有时，把引用设为null；必须缓存时改用WeakMap（键是DOM节点，节点销毁后自动清理）。 -
意外全局变量：非严格模式下漏写
let/const，写成data = new Array(1e6)，变量直接挂到window上，直到关页才释放。✅ 解法：所有文件顶部加"use strict"；编辑器开启ESLint规则no-implicit-globals；控制台留意隐式全局警告。 -
Detached DOM树：用
document.getElementById('modal')取到节点后存进cacheList，之后modal.remove()了，但cacheList还拿着它——节点已不可见，却占着样式、事件、子树全部内存。✅ 解法：移除DOM前先清空所有JS引用；避免用数组/对象长期持有DOM节点；真要关联数据，用WeakMap代替。
用Chrome DevTools三步定位真实泄漏
别靠猜，用工具验证。关键不是“看内存高不高”，而是“操作后是否回落”：
- 打开
Memory面板 → 点击Heap snapshot，刷新页面拍第一张（基线）； - 反复执行疑似泄漏的操作（比如打开/关闭5次弹窗）→ 拍第2、3张快照；
- 点右上角
Collect garbage（回收站图标）强制GC → 对比三次快照中Closure、HTMLDivElement、Array等构造函数的实例数是否只增不减；重点点开“Retaining Path”，看谁在强引用它。
如果发现Detached DOM tree数量持续增长，基本可锁定是DOM引用残留；若Closure下面堆着大量ArrayBuffer或ImageData，大概率是闭包没释放。
立即学习“Java免费学习笔记（深入）”；
预防比排查省十倍力气
很多泄漏根本不需要工具——只要在编码时多想半秒“这个引用什么时候该断”：
- 所有
setInterval/setTimeout的ID必须保存，并在unmount或beforeunload里调用clearInterval/clearTimeout； - 用
MutationObserver、ResizeObserver时，记得调用observer.disconnect()； - 框架里别滥用
ref或el缓存DOM，尤其在列表项渲染中； - 第三方库（比如图表、富文本）常自带内部监听和定时器，务必查文档看是否有
destroy或dispose方法。
最易被忽略的一点：泄漏往往不出现在“写新功能”时，而藏在“改旧逻辑”的缝隙里——比如给已有组件加个addEventListener，却忘了在卸载路径里补上清理。每次修改涉及异步、DOM、事件的地方，都该默念一遍“谁创建，谁清理”。
