JavaScript垃圾回收由引擎自动执行，依据可达性判断对象是否可回收；V8采用Scavenge（新生代）和Mark-Sweep/Mark-Compact（老生代）算法；隐式引用如未移除的事件监听器、未清除的定时器、DOM缓存等易致内存泄漏。
JavaScript 的垃圾回收机制不是你手动控制的，它由引擎自动运行，核心目标是识别并释放那些“不再被访问”的对象所占的内存。
什么是可达性（Reachability）——垃圾回收的判断依据
引擎不靠“有没有被 delete”或“变量是否已 undefined”来决定回收，而是看一个值是否能从根（如全局对象、当前执行上下文中的局部变量、活动函数参数等）通过引用链访问到。只要可达，就不会被回收。
-
let obj = { a: 1 };→obj是局部变量，指向的对象可达 -
obj = null;→ 引用断开，若无其他引用，该对象变成不可达，下次 GC 可能回收 - 闭包中捕获的外部变量，即使外层函数执行结束，只要闭包还活着，那些变量就仍可达
V8 中主要使用的两种回收算法：Scavenge 和 Mark-Sweep/Mark-Compact
V8 将堆内存分为新生代（new_space）和老生代（old_space），不同区域用不同策略，兼顾速度与空间效率。
- 新生代用
Scavenge算法：只复制存活对象到另一块半区（from-space → to-space），原空间直接清空。快但只适合小内存、短生命周期对象 - 老生代用
Mark-Sweep（标记-清除）或Mark-Compact（标记-整理）：先遍历标记所有可达对象，再清除未标记的；后者还会移动存活对象以减少碎片 - 频繁创建短命对象（如循环中
let arr = []）会快速填满新生代，触发 Scavenge；而长期存活对象（如全局缓存、DOM 引用）会晋升到老生代，GC 成本更高
哪些常见写法会意外阻止垃圾回收？
不是所有 null 赋值或作用域结束都能立即释放内存。真正的问题常出在隐式引用上。
立即学习“Java免费学习笔记（深入）”；
- 事件监听器没用
removeEventListener移除，且监听函数是匿名函数 → 回调无法被解绑，绑定的目标对象（如 DOM 元素）及其闭包依赖全被持留 - 定时器（
setInterval）里引用了外部大对象，且忘记clearInterval→ 定时器活跃时，回调及其中所有自由变量都保持可达 - 将 DOM 元素作为对象属性存储（如
cache[id] = element），又没在元素卸载时清理cache→ 即使元素从页面移除，JS 仍持有引用，无法被回收 - 使用
console.log(obj)在开发者工具中展开查看后，Chrome 有时会隐式保留对该对象的引用（尤其在断点暂停时），造成“疑似内存泄漏”假象
function setupHandler() {
const data = new Array(1000000).fill('leak');
document.body.addEventListener('click', () => {
console.log(data.length); // 闭包捕获 data
});
// ❌ 忘记 removeEventListener，data 永远不会被回收
}
真正难排查的不是“怎么触发 GC”，而是“为什么某个对象一直不被回收”。重点永远在检查引用链：谁还拿着它的引用？Chrome DevTools 的 Memory 面板 + Retainers 视图，比猜更可靠。
