JavaScript垃圾回收靠可达性判断对象是否该被清除：从根对象出发标记所有可访问对象，未被标记的不可达对象即被清除；可达性取决于引用链是否连通，而非delete或null赋值。
JavaScript 的垃圾回收机制靠什么判断对象该被清除？
JavaScript 的垃圾回收（GC）不依赖开发者手动释放，而是由引擎自动运行。主流引擎（V8、SpiderMonkey）使用标记-清除（Mark-and-Sweep）作为核心策略：从一组称为“根对象”（如全局对象、当前执行上下文中的局部变量、活动函数参数等）出发，递归标记所有可访问的对象；未被标记的即为不可达对象，随后被清除。
关键点在于：可达性是唯一标准——不是“有没有被 delete”，也不是“有没有被赋值为 null”，而是“从根能否通过引用链访问到它”。哪怕一个对象被赋值给某个闭包内的自由变量，只要该闭包还活跃，这个对象就始终可达，不会被回收。
哪些常见操作会意外保留引用导致内存泄漏？
内存泄漏本质是“本该不可达的对象，因某些引用未断开而持续可达”。以下是高频场景：
-
全局变量或意外挂载到
window/globalThis上的对象：比如忘记写const或let，直接赋值myData = {...}，它就成了全局属性，永远可达 -
未清理的事件监听器：用
addEventListener绑定后，若目标 DOM 元素已移除但没调用removeEventListener，且监听函数是匿名函数或闭包，就可能让整个作用域链滞留 -
定时器中持有外部作用域引用：例如在 React Class 组件的
componentDidMount中启动setInterval，回调里用了this.state，但组件卸载后定时器未清除，this无法释放 -
闭包过度捕获大对象：比如在循环中为每个元素绑定事件，回调里引用了整个数组
dataList而非仅需的item.id，会导致整个数组无法回收
WeakMap 和 WeakRef 真的能防泄漏吗？
它们的作用不是“防止泄漏”，而是避免强引用阻碍回收，适合做元数据关联或缓存。
立即学习“Java免费学习笔记（深入）”；
WeakMap 的键必须是对象，且是弱引用——如果该对象本身已不可达，即使它还在 WeakMap 中作为键，也不会阻止其被回收。常用于私有数据存储：
const privateData = new WeakMap();
class CacheItem {
constructor(value) {
privateData.set(this, { createdAt: Date.now(), value });
}
getValue() {
return privateData.get(this)?.value;
}
}
WeakRef 更底层，允许你持有对象的弱引用，并通过 ref.deref() 安全取值（可能返回 undefined）。但它不能替代显式清理逻辑，比如你仍需在合适时机调用 clearTimeout 或 removeEventListener。
注意：WeakMap 和 WeakRef 都不能解决 DOM 引用未断开、全局变量污染这类根本问题。
如何验证是否存在内存泄漏？
靠猜不行，得用工具定位。Chrome DevTools 是最直接的方式：
- 打开 Memory 面板 → 选中 Heap snapshot → 点击
Capture heap snapshot - 执行疑似泄漏的操作（如打开关闭某个模块多次）
- 再拍一次快照 → 在右上角下拉菜单选中前一个快照 → 切换到 Comparison 视图
- 重点关注
Constructor列中数量持续增长的类型，比如Closure、Object、Array，再点开看 retaining path（谁在引用它）
另一个有效方法是监控 performance.memory（需开启 Chrome 的 --enable-precise-memory-info 标志），观察 usedJSHeapSize 是否随操作稳定上升而不回落。不过该 API 在部分浏览器受限，不能作为唯一依据。
真正难的不是发现泄漏，而是理解 retaining path 里那一长串引用关系——往往要顺着闭包、事件监听器、定时器、框架内部缓存层层往下查，中间任何一环没断开，对象就卡在内存里不动。
