JavaScript垃圾回收由引擎自动执行，采用标记-清除为主、引用计数为辅的策略；根对象出发标记可达值，未标记者被清除；全局变量、未解绑事件监听器、未清理定时器及闭包中意外持有对象是常见泄漏源。
JavaScript 的垃圾回收是自动的，你无法手动触发或控制具体回收时机，但可以显著影响回收效率和内存驻留时间。关键不是“怎么调用 GC”，而是“怎么让引擎更快识别哪些值该被回收”。
哪些值会被自动回收？
JavaScript 使用标记-清除（Mark-and-Sweep）为主、辅以引用计数（仅用于循环引用检测优化）的混合策略。引擎会从一组根对象（如全局对象、当前执行上下文中的局部变量、闭包中捕获的变量）出发，递归标记所有可达值；未被标记的即为“不可达”，随后被清除。
常见误判场景：
- 全局变量或
window/globalThis上意外挂载的对象永远不会被标记为不可达 - 事件监听器未
removeEventListener，且回调引用了外部大对象 → 该对象因被闭包持有而长期驻留 -
setTimeout或setInterval的回调持续存活，其作用域链中的变量无法释放 - 数组或 Map 中保留已失效的引用（如已卸载组件的实例），即使逻辑上不再需要
delete 和赋值为 null 的区别
delete 操作符只对对象属性有效，它移除属性本身（包括键），但不保证立即释放内存——如果其他地方仍有对该值的引用，值依然存活。
立即学习“Java免费学习笔记（深入）”；
赋值为 null 是更直接的“断开引用”方式，尤其适用于局部变量、对象字段、数组元素：
let bigData = new Array(1000000).fill('payload');
// ✅ 主动释放引用
bigData = null;
const obj = { data: bigData };
obj.data = null; // 比 delete obj.data 更明确地切断引用
注意：delete obj.data 后，obj.data 变成 undefined，但若 bigData 还被其他变量持有，它仍不会被回收。
闭包与定时器：最隐蔽的内存泄漏源
闭包天然延长变量生命周期。问题不在闭包本身，而在“本该结束却没结束”的闭包。
典型模式：
- 异步回调（如
fetch）中引用了大型 DOM 元素或组件实例，但请求完成时组件早已unmount -
setInterval回调里持续访问已销毁对象的属性（如this.state） - 为 DOM 元素绑定事件后，未在元素移除时清理监听器，且监听器是闭包形式
解决方式不是避免闭包，而是加“存活检查”或“清理钩子”：
let timerId;
function startLoop() {
timerId = setInterval(() => {
if (!this.isValid) return; // ✅ 提前退出
doSomething(this.data);
}, 1000);
}
// 卸载时：
clearInterval(timerId);
this.isValid = false;
现代工具能帮你发现什么？
Chrome DevTools 的 Memory > Heap Snapshot 是最实用手段。重点关注：
- 按
Constructor排序，看Array、Object、Closure是否异常多 - 对比两个快照，用
Retained Size列找出“增长最多”的对象，右键Retaining paths查谁在持有着它 - 留意
(closure)类型下的长路径，尤其是跨模块/跨组件的引用链
注意：Performance > Record 中的内存曲线只能看趋势，不能定位具体对象；真正要确认泄漏，必须靠堆快照比对。
真正难处理的从来不是“怎么写回收代码”，而是“怎么让逻辑生命周期和引用生命周期严格对齐”。很多看似随机的内存增长，其实都卡在某个没被清理的 addEventListener 或漏掉的 abortController.abort() 上。
