怎样优化javascript性能_常见的内存泄漏如何避免？

内存泄漏主因是闭包、定时器、全局变量及事件委托不当导致dom或对象强引用无法释放；需显式清理监听器与定时器、用WeakMap替代直接挂载、避免隐式全局、细粒度事件委托并结合堆快照分析。

闭包中引用 DOM 元素导致的内存泄漏

闭包本身不是问题，但当它意外持有对 DOM 节点的强引用，且该节点已被移除时，就容易卡住整块内存。常见于事件监听器 + 闭包组合中。

比如：addEventListener 回调里用了外层函数变量，又没手动 removeEventListener，卸载组件后监听器仍活着，连带闭包捕获的 element、data 都无法回收。

• 始终用具名函数注册监听器，方便后续精准移除；匿名函数 + removeEventListener 无效
• 组件销毁（如 react 的 useEffect cleanup、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，可能锁住整个数据模块。查泄漏不能只盯代码，得靠快照比对 + 引用路径追踪。