JavaScript内存泄漏是悄无声息地耗尽内存，表现为Chrome中JavaScript Memory持续上涨直至卡死；主因包括未配对removeEventListener、未清除setInterval、闭包长期持有大对象，需主动解绑、清理和断引用。
JavaScript内存泄漏不是报错，而是“悄无声息地吃光内存”——你刷几次页面、开闭几次弹窗，Chrome任务管理器里 JavaScript Memory 那栏就 steadily 上涨，最后卡死或崩溃。它不警告你，只等你发现时已难定位。
为什么 removeEventListener 不配对就等于埋雷？
事件监听器泄漏最隐蔽也最常见：DOM节点被 removeChild 或 innerHTML = '' 清掉，但 JS 里还留着绑定的回调函数，而这个回调又闭包引用了大数组、组件实例甚至整个 document。GC 一看：“这函数还在被监听器列表引用”，就谁也不敢动它。
- 必须用具名函数（不能用匿名箭头函数）才能精准解绑：
const handleClick = () => { /* ... */ };
button.addEventListener('click', handleClick);
// 卸载时
button.removeEventListener('click', handleClick); - 在 React 中，
useEffect返回函数是天然解绑时机；Vue 用onBeforeUnmount；纯 JS 动态创建的模块，得自己记下监听器并统一清理 - 别依赖
{ once: true }当万能解药——它只防重复触发，不解决“监听器注册后 DOM 就没了”的场景
setInterval 忘了 clearInterval，就是在后台养僵尸函数
一个没清理的 setInterval，哪怕只执行一行 console.log，它的回调函数 + 整个闭包作用域都会常驻内存。更危险的是：单页应用路由跳走后，定时器还在跑，还持续拉接口、更新状态、引用旧组件实例。
- 务必保存 ID：
const timerId = setInterval(...)，而不是直接写setInterval(...) - 清理时机要明确：组件卸载、
visibilitychange监听到页面隐藏、或业务逻辑中“该功能已退出”时立刻clearInterval(timerId) - 避免用
setInterval做轮询；改用setTimeout递归 + 条件控制，这样每次都能主动决定“下一次还启不启动”
闭包持有大对象，不是“用了闭包”，而是“忘了断引用”
闭包本身不是问题，问题是它让本该释放的变量“赖着不走”。比如一个上传组件返回的 pause 函数，内部闭包引用了 fileBuffer（20MB ArrayBuffer），用户关掉弹窗后，只要 pause 还挂在某个全局对象上，这块内存就永远锁死。
立即学习“Java免费学习笔记（深入）”；
- 不要把大对象（
ArrayBuffer、ImageBitmap、大量 JSON 数据）塞进闭包长期持有 - 真需要关联 DOM 和数据，优先用
WeakMap：const metadata = new WeakMap();
metadata.set(domEl, { lastClickTime: Date.now() }); // domEl 被 GC 后，键值对自动消失 - 业务结束时，主动切断引用：
cacheRef = null、uploader.pause = null，给 GC 明确信号
怎么确认是不是泄漏？别猜，用 Chrome Memory 面板实锤
靠感觉判断内存是否上涨太慢，而且容易误判。真正高效的方式是录制堆快照比对：
- 打开 DevTools →
Memory面板 → 选Heap snapshot - 刷新页面，拍第一张（baseline）；然后反复执行疑似泄漏操作（如打开/关闭模态框 3 次）；再拍 2–3 张
- 点右上角
Collect garbage（回收站图标），强制 GC；如果某类对象（如Closure、HTMLDivElement、Array）数量只增不减，就是泄漏铁证 - 重点看
Retaining Path：它会告诉你“谁在强引用这个对象”，比如window.myGlobalCache → closure → largeArray，顺藤摸瓜就能定位到那行漏清的myGlobalCache = [...]
最难防的不是技术盲区，而是“我以为它自己会走”——比如以为移除 DOM 就万事大吉，其实 JS 变量还攥着引用；以为组件 unmount 了监听器就自动销毁，其实没手动解绑。内存泄漏从不声张，只等你某天面对卡顿页面，翻遍代码却找不到源头。
