闭包、事件监听器、定时器、全局变量和缓存管理不当是JavaScript内存泄漏的主要原因，需通过Chrome DevTools分析堆快照、监控分配时间线并结合代码审查与自动化工具进行排查和预防。
JavaScript中的内存泄漏虽然不像传统系统语言那样常见，但由于其自动垃圾回收机制的局限性，依然可能在特定场景下悄然发生。尤其是一些看似无害的代码模式，长期运行后会逐渐消耗内存，导致页面变慢甚至崩溃。下面介绍几种隐蔽的成因及对应的排查方法。
1. 闭包引用导致的变量无法释放
闭包是JavaScript的强大特性，但也容易造成内存泄漏。当一个函数返回另一个函数，并且内部函数引用了外部函数的变量时，这些变量不会被垃圾回收，即使外部函数已经执行完毕。
例如：
function createLeak() {let largeData = new Array(1000000).fill('data');
return function() {
console.log(largeData.length); // 引用了largeData
};
}
const leakFn = createLeak(); // largeData一直驻留在内存中
建议：避免在闭包中长期持有大对象引用。如果不再需要，显式将其设为 null。
立即学习“Java免费学习笔记（深入）”；
2. 未清理的事件监听器
DOM元素被移除后，若仍绑定有事件监听器，且监听器引用了外部变量或this上下文，该元素及其相关作用域可能无法被回收。
常见于单页应用中动态添加又未移除的监听器：
element.addEventListener('click', handler);// 后续removeChild(element)，但未调用removeEventListener
建议：使用 addEventListener 的同时，确保在适当时机调用 removeEventListener。对于一次性事件，可使用 { once: true } 选项。现代框架（如React、Vue）通常会自动管理，但自定义DOM操作需格外注意。
3. 被遗忘的定时器或回调
setInterval 或 setTimeout 中的回调函数若持续引用外部变量或组件实例，即使组件已卸载，定时器仍在运行，导致内存无法释放。
典型场景：SPA中组件销毁后，interval未清除。
setInterval(() => {console.log(this.someComponentData); // this可能已失效
}, 1000);
建议：在组件销毁或逻辑结束时调用 clearInterval 或 clearTimeout。使用WeakMap存储定时器ID有助于追踪和清理。
4. 意外的全局变量引用
未声明的变量会成为全局对象（window）的属性，而全局变量不会被垃圾回收。
function leakyFunction() {leakedVar = 'I am global now'; // 忘记加var/let/const
}
建议：启用严格模式（'use strict'），让此类错误抛出异常。定期检查全局对象上的意外属性。
5. 缓存未设上限或清理机制
开发者常使用对象或Map做缓存，但若不设大小限制或过期策略，数据会无限增长。
const cache = new Map();function getData(key) {
if (cache.has(key)) return cache.get(key);
// 获取数据并存入cache，但从不清空
}
建议：使用 WeakMap 或 WeakSet 存储仅用于关联对象的元数据，它们不会阻止键对象被回收。对于强缓存，实现LRU等淘汰策略。
排查方法
发现内存问题后，可通过以下方式定位：
- Chrome DevTools Memory面板：拍摄堆快照（Heap Snapshot），查看对象数量和保留大小，查找重复或异常的大对象。
- 记录内存分配时间线：使用“Record Allocation Timeline”功能，观察内存增长与代码执行的对应关系。
- 监控Event Listener数量：在Elements面板查看DOM节点是否附着过多监听器。
- 代码审查：重点关注闭包、事件绑定、定时器、全局变量和缓存逻辑。
- 自动化检测：结合Performance API或第三方工具（如Sentry）监控长时间运行下的内存趋势。
基本上就这些。内存泄漏往往不是一目了然的问题，关键在于养成良好的资源管理习惯，并借助工具定期检查。
