垃圾回收靠标记-清除算法判断对象是否该被清理：从根对象出发递归标记可达对象，未标记的即为不可达垃圾；引用计数法因无法处理循环引用而被淘汰。
JavaScript内存管理由引擎自动完成，开发者不需手动分配或释放内存。核心在于垃圾回收器（GC）周期性识别并清理“不可达对象”，防止内存泄漏。它不是实时运行，而是在内存压力增大、空闲时段或执行上下文切换时触发。
垃圾回收靠什么判断一个对象该被清理？
现代引擎（如V8）主要用标记-清除（Mark-and-Sweep）算法，不依赖引用计数：
- 从一组“根对象”出发（如全局对象、当前执行上下文中的变量、栈中活跃引用），递归遍历所有可达对象，并打上“存活”标记
- 遍历完成后，未被标记的对象即为“不可达”，被视为垃圾，所占堆内存被统一回收
- 这种机制天然解决循环引用问题——即使
obj1.ref = obj2且obj2.ref = obj1，只要二者都脱离全局或任何活动上下文，它们都不会被根可达，仍会被回收
为什么早期的引用计数法被淘汰了？
引用计数曾用于部分旧浏览器（如IE6–8），但存在根本缺陷：
- 每个对象维护一个计数器，每次新增引用+1，解除引用−1
- 一旦两个对象互相引用（
a.b = b; b.a = a），它们的计数永远≥1，即使外部已无任何引用，也无法归零 - 这会导致内存持续占用，形成隐性泄漏，尤其在DOM与JS对象交叉引用时高发（如
element.obj = myObj; myObj.el = element）
哪些操作容易干扰垃圾回收？
虽然GC自动运行，但代码写法会影响对象是否及时变为“不可达”：
立即学习“Java免费学习笔记（深入）”；
-
全局变量残留：意外挂载到
window或globalThis上的对象会长期存活 -
未清理的定时器或事件监听器：如
setInterval回调中持有大对象引用，或addEventListener未配对removeEventListener - 闭包过度捕获：内部函数无意中保留对外部大作用域（如大型数组、DOM节点）的引用
- 缓存未设上限或未失效：比如用对象做LRU缓存但不淘汰旧项，导致内存只增不减
开发者能做什么来配合GC？
不需要手动调用GC，但可以主动“断开引用”，让对象更快进入不可达状态：
- 不再需要的变量，显式赋值为
null（尤其对大对象、DOM引用、事件处理器） - 使用
WeakMap或WeakSet存储关联数据——它们的键是弱引用，不影响GC判定 - 移除DOM节点前，先解绑其绑定的事件和自定义属性引用
- 用
const替代不必要的let，减少意外重赋值带来的引用延长
