JavaScript垃圾回收本身不影响性能，但不当内存使用会导致GC频繁触发、主线程暂停，引发卡顿或崩溃；其核心是标记-清除机制，仅回收不可达对象，而闭包捕获、未解绑事件监听器等会使对象持续可达，造成内存泄漏。
JavaScript 的垃圾回收（GC）本身不直接“影响性能”，但不当的内存使用会让 GC 频繁触发、暂停主线程，造成卡顿、内存持续增长甚至崩溃。这不是 GC 太慢，而是你留了太多它本该回收却无法回收的东西。
什么是可达性？GC 判断“该不该回收”的唯一标准
JavaScript 使用标记-清除（mark-and-sweep）机制，核心逻辑极简单：从全局对象（window 或 globalThis）、当前执行栈等根对象出发，顺着引用链能访问到的对象视为“可达”，其余一律回收。
这意味着：一个闭包意外捕获了大数组，或一个事件监听器没被移除，哪怕 DOM 节点已从页面删除，只要还有 JS 引用指向它，它就永远“可达”——GC 永远不会碰它。
- 全局变量、定时器回调、未清理的
addEventListener回调，都是常见“隐式根” -
WeakMap和WeakRef不会阻止回收，适合缓存或关联元数据 -
console.log(obj)会临时保留引用（尤其在 DevTools 打开时），干扰判断，别靠它验证是否泄漏
Chrome DevTools 中定位真实内存泄漏的三步法
别只看内存图表“涨了”，要确认是不是真泄漏。重点看“堆快照对比”和“分配采样”：
立即学习“Java免费学习笔记（深入）”；
- 打开 Memory 面板 → 选 Heap snapshot → 点 Capture snapshot（操作前、后各一次）
- 切换到第二个快照 → 在左上角 Filter 输入
Detached，查看“分离但仍有引用”的 DOM 节点（典型泄漏信号） - 右键某构造函数（如
Array、Object）→ Retainers，看谁在持有它；再点 Retaining paths，找最长那条非预期引用链 - 若怀疑频繁小对象泄漏，改用 Allocation sampling，它不卡主线程，能暴露哪些函数在持续分配未释放对象
高频泄漏场景与对应预防写法
以下不是理论，是线上真实踩坑点：
- 事件监听器未解绑：
element.addEventListener('click', handler)后，必须在元素销毁时调用element.removeEventListener('click', handler)；用{ once: true }或AbortController更安全 - 闭包中保留大对象：
function createProcessor(data) { return () => console.log(data.length); }——data会被整个闭包持有；改用data.length等必要字段传入，或显式清空引用（data = null） - 定时器未清理：
setInterval(() => {...}, 100)在组件卸载后仍在跑，且闭包引用着组件实例；务必保存 timer ID 并在clearInterval(id)，React 中放在useEffect清理函数里 - 第三方库缓存失控：比如某些图表库内部用
Map缓存 DOM 引用，但没提供销毁方法；检查其 API 是否有.destroy()，或手动清空其私有缓存字段（需阅读源码）
WeakMap / WeakRef 不是万能解药，用错反而更难调试
它们只在“弱引用”场景有效，且行为不可预测（GC 时机不确定）：
-
WeakMap键必须是对象，且仅用于“对象 → 元数据”映射；不能遍历、不能查 size；别试图用它替代普通Map -
WeakRef+.deref()返回可能为undefined，每次访问都得判空；不适合需要稳定引用的逻辑（如动画帧回调中反复读取） - 真正适合 WeakRef 的场景极少：比如实现一个不阻止目标对象被回收的“观察者注册表”，或避免循环引用导致的泄漏
多数时候，明确的生命周期管理（创建 → 使用 → 销毁）比依赖弱引用更可靠、更易测试。GC 不是你该对抗的敌人，而是你内存契约的守门人——契约写错了，它只是如实执行而已。
