JavaScript 垃圾回收靠可达性判断对象是否可回收，即从根对象出发标记所有可达对象，未被标记的不可达对象被清除；不依赖引用计数或变量名是否存在。
JavaScript 的垃圾回收机制靠什么判断对象可回收？
JavaScript 引擎（如 V8）主要用标记-清除（Mark-and-Sweep）机制自动回收内存，不依赖引用计数。它从一组根对象（如全局对象、当前执行上下文中的局部变量、活动函数参数等）出发，递归标记所有可达对象；未被标记的对象即被视为“不可达”，随后被清除。
关键点在于：可达性（reachability）才是决定是否回收的唯一标准，不是“有没有变量名指向它”。比如一个对象被闭包内部函数持有，即使外部变量已设为 null，它仍可达，不会被回收。
常见误判场景：
- 以为
obj = null就立刻释放内存 → 实际只是断开一个引用，若还有其他引用（如事件监听器、闭包、缓存 Map 中的 key）仍存在，对象继续存活 - 认为定时器回调执行完就自动清理其捕获的变量 → 若回调是闭包，且被长期持有的 timer ID 引用（如未
clearInterval），整个作用域链可能滞留 - 把 DOM 节点和 JS 对象混为一谈 → 移除 DOM 节点不等于解除 JS 引用；若仍有 JS 变量（如
const el = document.getElementById('x')）或事件监听器绑定着它，节点无法被 GC
哪些典型模式会引发内存泄漏？
内存泄漏本质是“本该被回收的对象因意外强引用而持续驻留”。以下是最常踩的坑：
立即学习“Java免费学习笔记（深入）”；
-
未移除的事件监听器：给全局或长生命周期对象（如
window、document、单例模块）添加监听器，但组件卸载或逻辑结束时没调用removeEventListener - 闭包中保留大对象引用：回调函数无意中捕获了大型数组、JSON 数据或 DOM 集合，且该回调被长期持有（如挂到定时器、Promise 链、或作为事件处理器未解绑）
-
全局变量意外增长：忘记用
var/let/const声明变量 → 自动挂到window（浏览器）或global（Node.js），例如data = fetchData() -
定时器未清理：使用
setInterval但忘记clearInterval，尤其在 SPA 页面切换、React 组件卸载、VuebeforeUnmount等时机 -
Map/Set 持有 DOM 节点作 key：如
cacheMap.set(domEl, data)，DOM 节点被移除后，cacheMap仍强引用它，阻止 GC；应改用WeakMap（只接受对象作 key，且是弱引用）
如何用 WeakMap 和 WeakRef 主动降低引用强度？
WeakMap 和 WeakRef 是 ES2015+ 提供的、专为避免内存泄漏设计的工具。它们不阻止垃圾回收，适合做“附属元数据”存储。
优先选 WeakMap 的场景：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
- 给 DOM 元素附加私有状态（如拖拽坐标、加载状态），又不想阻止元素被回收
- 实现对象级缓存，key 是目标对象本身，value 是计算结果
示例：用 WeakMap 缓存 DOM 元素尺寸，无需手动清理
const sizeCache = new WeakMap();
function getCachedSize(el) {
if (sizeCache.has(el)) {
return sizeCache.get(el);
}
const size = { width: el.offsetWidth, height: el.offsetHeight };
sizeCache.set(el, size);
return size;
}
// el 被 remove() 后，sizeCache 中对应 entry 自动失效，无泄漏风险
WeakRef 更底层，适用于需要“尝试访问”一个可能已被回收的对象：
- 缓存大型资源（如 canvas 上下文、WebGL 纹理），但允许 GC 在内存紧张时回收
- 实现软引用式观察者模式（需配合
FinalizationRegistry清理副作用）
注意：WeakRef 不适合常规业务逻辑，API 复杂且时机不可控，WeakMap 覆盖 90% 场景。
调试内存泄漏的实操步骤有哪些？
别猜，用 Chrome DevTools 的 Memory 面板直接观测。核心动作是“对比快照”：
- 打开
DevTools → Memory → Take heap snapshot - 执行疑似泄漏的操作（如打开/关闭弹窗、切换路由、反复增删列表）
- 再拍一张快照，用
Comparison视图筛选 “Objects allocated between snapshots” - 重点关注
(closure)、HTMLDivElement、Array等类型数量是否异常增长 - 点击某构造函数，在右侧看“Retainers”列 → 找出谁在强引用它（常见是
Window、setInterval、闭包变量、事件监听器）
命令行辅助排查：
-
console.memory查看当前 JS 堆大小（单位字节） -
% gc（V8 内部命令，需开启--allow-natives-syntax）强制触发 GC，验证是否真泄漏 - Node.js 可用
process.memoryUsage()监控 RSS 和 heapUsed
真正难的是识别“间接引用链”——比如一个 setTimeout 回调闭包里用了某个对象，而这个 timer 又被挂到了全局对象上。这种链路必须靠快照 Retainers 一层层点进去看，没法靠代码静态扫描发现。
