JavaScript引擎通过标记-清除算法决定对象是否可回收：从根对象出发标记所有可达对象，未被标记的即为不可达而被清除；引用计数因无法处理循环引用已被弃用。
JavaScript 引擎怎么决定哪些对象可以回收
JavaScript 的垃圾回收（GC）不靠开发者手动释放，而是由引擎自动运行。主流引擎（V8、SpiderMonkey）用的是标记-清除（Mark-and-Sweep）算法：先从根对象（如全局对象、当前执行上下文中的变量）出发，递归标记所有能被访问到的对象；未被标记的，就被视为“不可达”，随后被清除。
注意：引用计数在早期 IE 中用过，但因无法处理循环引用（比如 a.ref = b; b.ref = a）已被现代引擎弃用。V8 从不依赖引用计数做主回收逻辑。
闭包和事件监听器是最常见的泄漏源头
闭包会隐式延长其词法作用域中变量的生命周期；事件监听器若没被显式移除，会一直持有回调函数及其捕获的变量——哪怕 DOM 元素已被 remove() 或页面跳转。
- 避免在定时器或事件回调中长期持有大对象（如整个
document、JSON.parse后的巨型数据） - 使用
addEventListener时，优先配合{ once: true }，或在组件卸载/销毁时调用removeEventListener - Vue/React 等框架中，务必在
onUnmounted或useEffect的清理函数里清除副作用
let data = new Array(1000000).fill('leak');
document.addEventListener('click', () => {
console.log(data.length); // data 被闭包捕获，无法回收
});
定时器和 Promise 链容易拖住本该释放的对象
setTimeout、setInterval 和未完成的 Promise（尤其是 Promise.resolve().then(...) 链）都会维持对其中闭包变量的引用，直到回调执行完毕。如果定时器未清除，或 Promise 长期 pending（比如网络请求永不响应），相关对象就一直驻留内存。
立即学习“Java免费学习笔记（深入）”；
- 给
setInterval设定 ID，并在不需要时调用clearInterval(id) - 对可能长期 pending 的 Promise，加超时控制（如用
AbortController或封装Promise.race([fetch(), timeout()])） - 避免在 Promise 回调中直接引用外部大对象；必要时用弱引用结构（如
WeakMap缓存）
Chrome DevTools 怎么确认是不是真泄漏了
别只看内存占用数字上涨——那是正常波动。关键是看多次重复操作后，内存是否阶梯式上升且不回落。用 Chrome 的 Memory 面板做快照对比：
- 操作前拍一个快照（
Heap snapshot） - 执行疑似泄漏的操作（如打开关闭模态框 5 次）
- 强制 GC（点击垃圾桶图标），再拍一个快照
- 切换到
Comparison视图，筛选Retained Size大幅增加、且类型为Closure或Object的条目 - 点开看 “Retainers” 列，找到谁在持有着它（常见是
timer、eventListener、global）
特别注意：Detached DOM tree 类型对象大量存在，基本等于泄漏——说明 DOM 节点已从文档移除，但 JS 仍通过变量、闭包或事件监听器引用着它。
const foo = bar 是不是还在某个闭包链或事件注册表里挂着。 
