JavaScript内存泄漏表现为页面卡顿、内存不回落、长时间运行后崩溃，根本原因是本该回收的对象因未断开引用而滞留内存；可用Chrome DevTools Memory面板通过三次堆快照比对Closure、Detached HTMLDivElement等对象是否只增不减，并查看Retaining Path定位强引用源。
JavaScript内存泄漏不是报错，而是页面越来越卡、切换路由后内存不回落、长时间运行后崩溃——根本原因是本该被回收的对象，因为某些引用没断开，一直“赖”在内存里。
怎么用 Chrome DevTools 快速确认是不是泄漏
别猜，直接看数据：打开 Chrome DevTools → Memory 面板，按三步操作就能验证：
- 刷新页面，点击
Take Heap Snapshot拍第一张快照（基线） - 执行疑似泄漏的操作（比如反复打开/关闭弹窗、切换列表页），再拍 2–3 次快照
- 选中后两张快照，切换到
Comparison视图，重点关注Closure、HTMLDivElement、Detached HTMLDivElement、Array这几类是否持续新增且不减少
如果某类对象数量只增不减，点开它的 Retaining Path（保留路径），就能看到谁在强引用它——比如某个闭包持有了一个 document.getElementById('xxx') 返回的节点，而这个节点早就被 removeChild 掉了，但变量还活着。
为什么 removeEventListener 不配对调用就会泄漏
事件监听器本身是个函数，它会形成闭包，捕获外部作用域里的变量（比如组件状态、API 响应数据、DOM 节点）。一旦绑定后没解绑，即使 DOM 元素被移除、组件已卸载，这个函数和它闭包里的所有东西都还在内存里。
- 常见错误：
button.addEventListener('click', handler)写了，但没在组件销毁时写button.removeEventListener('click', handler) - React 中漏掉
useEffect的清理函数；Vue 中忘了beforeUnmount里的解绑逻辑 - 更隐蔽的是委托监听：给
document绑了scroll，却没在离开页面前清除，滚动回调里又用了this.data或ref，整个上下文就被锁死了
✅ 正确做法：所有 addEventListener 都要配对 removeEventListener；优先用事件委托 + 条件判断，而不是给每个元素单独绑定；或者统一用 AbortController.signal 控制监听生命周期（现代 API）。
setInterval / setTimeout 清不干净的后果比你想的严重
一个没清除的 setInterval 不只是多跑一次回调——只要回调里引用了任何外部变量（哪怕只是 console.log(this.id)），这些变量就永远无法被 GC 回收。尤其在单页应用里，用户切走页面后定时器还在跑，内存曲线会阶梯式抬升。
- 错误写法：
setInterval(() => { fetchData(); }, 5000)，没有保存 ID，也没清理 - 更危险的是：把定时器 ID 存在局部变量里，但组件销毁时没清，比如函数执行完就丢了引用
- 推荐管理方式：用
Map或数组集中存所有 ID，在unmount/destroy时遍历调用clearInterval；或封装一个useIntervalHook，内部自动清理
⚠️ 注意：setTimeout 同样危险——比如防抖函数里用 setTimeout 设置了延迟执行，但新请求来了没 clearTimeout，旧的 timeout 就成了“幽灵引用”。
DOM 节点被删了，为什么还在内存里
这是最常被忽略的泄漏点：let btn = document.getElementById('submit-btn') 拿到节点后，你调用了 btn.remove() 或 parent.removeChild(btn)，但 JS 里 btn 变量还持有它。这个节点虽然从文档树脱离，但 JS 引用链仍在，它连带
Detached HTMLButtonElement。
- 典型场景：缓存 DOM 节点用于快速复用（比如弹窗模板），但弹窗关闭后没清空缓存变量
- 错误习惯：用普通对象或数组长期存 DOM 引用，比如
cache['modal'] = modalEl，后续没删 - ✅ 解法：移除节点后，主动将相关变量设为
null；改用WeakMap存关联数据（键是 DOM 节点，节点被回收时自动清理）；避免全局或长生命周期对象持有 DOM 引用
真正难的不是发现泄漏，而是意识到“删了 DOM”不等于“释放了内存”——JS 引用比 DOM 结构更顽固，得手动切断。
