内存泄漏主因是闭包、定时器、全局变量及事件委托不当导致DOM或对象强引用无法释放；需显式清理监听器与定时器、用WeakMap替代直接挂载、避免隐式全局、细粒度事件委托并结合堆快照分析。
闭包中引用 DOM 元素导致的内存泄漏
闭包本身不是问题，但当它意外持有对 DOM 节点的强引用，且该节点已被移除时，就容易卡住整块内存。常见于事件监听器 + 闭包组合中。
比如：addEventListener 回调里用了外层函数变量，又没手动 removeEventListener，卸载组件后监听器仍活着，连带闭包捕获的 element、data 都无法回收。
- 始终用具名函数注册监听器，方便后续精准移除；匿名函数 +
removeEventListener无效 - 组件销毁（如 React 的
useEffectcleanup、Vue 的beforeUnmount）时，必须显式调用removeEventListener - 避免在闭包中直接缓存整个 DOM 节点，改用
element.id或dataset存标识，需要时再查
定时器未清除引发的持续引用
setTimeout 和 setInterval 的回调函数会形成闭包，若回调内引用了外部大对象（如 hugeArray、renderedCanvas），而定时器没被 clearTimeout/clearInterval 清理，就会一直阻止 GC。
尤其在 SPA 页面跳转、弹窗关闭后，忘记清理定时器是高频泄漏源。
立即学习“Java免费学习笔记（深入）”；
- 所有
setTimeout/setInterval必须配对管理：保存返回值（timerId），并在退出场景下明确清除 - 不要依赖「页面隐藏」或「组件 unmount」自动清理——浏览器不保证，必须手动
- 考虑用
requestIdleCallback替代低频轮询，它天然受生命周期约束，且更省资源
全局变量和意外挂载的属性
把数据挂到 window、globalThis 或无意中创建隐式全局变量（如漏写 let/const），会导致对象永远可访问，GC 完全绕过。
还有更隐蔽的：给 DOM 节点添加自定义属性时用了对象引用而非字符串，例如 node.__cache = largeObject —— 这个引用不会随节点移除而消失。
- 禁用隐式全局：开启严格模式（
"use strict"），ESLint 开启no-implicit-globals - 避免直接往 DOM 节点挂复杂对象；改用
WeakMap关联数据：const cache = new WeakMap(); cache.set(element, data);
——WeakMap键是弱引用，节点被删后自动解绑 - 检查
console.log是否误留大对象引用（某些调试器会保持引用），生产环境禁用冗余日志
事件委托不当放大泄漏范围
用 document.addEventListener('click', handler) 做全局委托很常见，但如果 handler 是闭包且内部引用了已卸载模块的实例（比如某个 Vue 组件的 this），这个 handler 就成了泄漏入口。
它不像组件内监听器那样随组件销毁自动解绑，而是长期驻留。
- 全局委托的 handler 应尽量无状态、无外部引用；必要时用
WeakRef包裹外部实例（需现代环境支持） - 优先使用更细粒度的委托容器（如
app-root元素），而不是document或window - 定期审查
Performance.memory和 Chrome DevTools 的Memory > Heap Snapshot，筛选出长期存活的非预期对象（如重复出现的组件类实例）
WeakMap 没清空，可能牵出十个闭包；一个没清除的 setInterval，可能锁住整个数据模块。查泄漏不能只盯代码，得靠快照比对 + 引用路径追踪。 
