javascript垃圾回收基于可达性：从根对象出发无法访问的值才会被回收；delete不释放内存，切断所有引用才有效；weakmap/weakref提供弱持有避免泄漏；v8分代回收，新生代用scavenge，老生代用mark-sweep/compact。
JavaScript 的垃圾回收机制不归你管——你只能影响它，不能控制它。V8 引擎（Chrome、Node.js）用的是分代式垃圾回收
哪些变量会被自动回收？
核心判断标准只有一个：该值是否还存在可达的引用链。不是“有没有被 delete”，也不是“有没有被赋值为 null”，而是从根对象（如 globalThis、当前执行上下文的活动记录）出发，能否顺着引用找到它。
常见误判场景：
- 闭包中捕获的外部变量，即使外层函数已返回，只要内层函数还存活，那些变量就不会被回收
-
setTimeout或setInterval回调里引用了大对象，定时器没清除，对象就一直活在内存里 - 事件监听器没用
removeEventListener解绑，且监听器是匿名函数时，几乎无法手动释放 - DOM 元素被移除但 JS 仍持有其引用（比如缓存在
const cache = new Map()中），该元素及其子树不会被回收
WeakMap 和 WeakRef 怎么帮上忙？
它们不阻止垃圾回收，只提供“弱持有”能力，适合做缓存或元数据绑定，避免内存泄漏。
立即学习“Java免费学习笔记（深入）”；
WeakMap 键必须是对象，且键对象被回收后，对应条目自动消失：
const cache = new WeakMap();
function expensiveCalc(obj) {
if (cache.has(obj)) return cache.get(obj);
const result = /* ... */;
cache.set(obj, result); // obj 被回收 → 条目自动清理
return result;
}WeakRef 更底层，允许你临时持有对象并手动检查是否还活着：
- 不能用于普通变量替代（
ref.deref()可能返回undefined） - 配合
FinalizationRegistry可在对象被回收后触发清理逻辑（比如关闭资源、注销回调） - 注意：
FinalizationRegistry的回调时机不确定，不能依赖它做关键状态同步
V8 中哪些操作会触发 GC？
你无法主动调用 GC（gc() 只在 V8 命令行调试模式下可用，生产环境禁用），但可以观察和间接影响：
- 新生代（Scavenge）：小对象分配频繁，当 from-space 满时立即触发，速度快（毫秒级）
- 老生代（Mark-Sweep / Mark-Compact）：大对象或多次熬过 Scavenge 后晋升至此；通常由内存压力触发（比如堆使用率超阈值），耗时更长（10–100ms）
- 内存增长快、频繁创建短生命周期对象（如循环中生成新数组/对象），会加速 GC 频率，拖慢脚本执行
可通过 Chrome DevTools 的 Memory 面板录制 Allocation Timeline，看哪些构造函数持续分配未释放的对象。
为什么 delete 不等于释放内存？
delete 只删除对象自身的可配置属性，对内存无直接影响。它既不触发 GC，也不清空值所占空间：
const obj = { huge: new Array(1e6).fill('data') };
delete obj.huge; // 属性没了，但数组仍被 obj 持有？不，这里只是删了引用
// 实际上：obj.huge 已不存在，数组若无其他引用，下次 GC 会回收真正起作用的是切断所有引用：
- 设为
null、undefined或新值（前提是旧值没有其他引用） - 从数组中
splice或pop掉引用项 - 退出作用域（函数执行结束，局部变量自动不可达）
最易忽略的一点：全局变量、window（浏览器）或 global（Node）上的属性永远不会被 GC，除非显式赋值覆盖或 delete（且属性可配置）。
