JavaScript垃圾回收通过标记-清除算法判断对象是否可回收：从全局对象等根出发，递归标记所有可达对象，未被标记的即不可达而被回收；循环引用问题使引用计数法被弃用。
JavaScript 垃圾回收怎么判断一个对象该被回收？
JavaScript 的垃圾回收器（GC）不靠程序员手动释放，而是自动运行。它主要用 标记-清除（Mark-and-Sweep） 算法：从全局对象（window 或 globalThis）、当前执行上下文的局部变量等“根”出发，递归标记所有能访问到的对象；没被标记的，就被判定为不可达，随后被清除。
注意：引用计数（Reference Counting） 在早期 IE 中用过，但因无法处理循环引用（比如 a.ref = b; b.ref = a）已被主流引擎弃用。现代 V8、SpiderMonkey、JavaScriptCore 全部基于标记-清除或其变种（如 V8 的分代式 GC + 增量标记）。
所以关键不是“谁创建了对象”，而是“还有没有活的引用链能触达它”。只要存在一条从根出发的引用路径，哪怕你已经不用它了，它也不会被回收。
闭包不小心保留了外层作用域，是最常见的泄漏源头
闭包本身不是问题，问题在于闭包函数长期存活，又持有对外层变量的引用，而这些变量本该随外层函数结束而消失。
立即学习“Java免费学习笔记（深入）”；
- 典型场景：事件监听器里用了闭包，但监听器没被移除（比如绑定在
document上），导致整个外层作用域被钉住 - 定时器回调中引用了大数组或 DOM 节点，且
setTimeout/setInterval没被clearTimeout/clearInterval清理 - 把局部变量赋给全局对象（如
window.cache = bigData），或者意外挂到this上（类方法未绑定时，被当作普通函数调用，this指向全局）
function createHandler() {
const hugeArray = new Array(1000000).fill('data');
return function() {
console.log(hugeArray.length); // 闭包捕获了 hugeArray
};
}
const handler = createHandler();
// 如果 handler 被长期持有（比如设为某个按钮的 onclick），hugeArray 就不会被回收
DOM 引用没清理，尤其在单页应用中特别危险
DOM 节点被 JS 引用时，即使它已从文档中 remove() 或 innerHTML = '' 清空，只要 JS 还有变量指向它，它和它的整个子树就仍在内存中。
- 缓存 DOM 节点但忘记在组件卸载时清空（React 中未在
useEffect的 cleanup 函数里解绑，Vue 中未在beforeUnmount里清理） - 使用
addEventListener绑定了匿名函数，后续无法用removeEventListener移除（因为匿名函数每次都是新引用） - 用
Map或WeakMap存储 DOM 相关元数据时，误用了强引用的Map—— 应优先用WeakMap，它不会阻止键所指 DOM 被回收
// ❌ 错误：用 Map 持有 DOM 节点作为 key → 节点无法被 GC
const metadataMap = new Map();
metadataMap.set(document.getElementById('app'), { timestamp: Date.now() });
// ✅ 正确：WeakMap 不会阻止 key（DOM 节点）被回收
const metadataWM = new WeakMap();
metadataWM.set(document.getElementById('app'), { timestamp: Date.now() });
哪些操作看起来 harmless，其实悄悄吃内存？
有些写法看似无害，但在高频或长生命周期场景下会累积泄漏：
-
console.log(obj)在 Chrome DevTools 打开时，会保持对obj的引用（用于后续展开查看），关闭控制台后才可能释放 —— 生产环境不影响，但调试时别 log 大对象 - 频繁生成并丢弃正则对象（如
/pattern/g字面量在循环里），V8 会缓存它们，但缓存有上限；更稳妥的是复用RegExp实例（new RegExp('pattern', 'g')）并手动管理 - 使用
eval或Function构造函数动态创建函数，会创建无法被静态分析的作用域链，干扰 GC 判断 - Web Workers 中未正确关闭或未
postMessage后及时terminate()，Worker 实例及其全部堆内存持续驻留
真正难排查的泄漏，往往不是某一行代码，而是多个小引用叠加形成的“引用网”——比如一个未注销的事件监听器 → 持有回调函数 → 回调闭包引用了组件实例 → 实例上有对 DOM 和数据的引用。得用 Chrome DevTools 的 Memory 面板拍快照、对比、筛选 Detached DOM tree，才能定位到根因。
