JavaScript垃圾回收通过可达性判断内存是否该回收：从根对象出发能访问到的对象被保留，否则被回收；闭包、事件监听器、定时器等易导致意外引用而泄漏；需主动解绑、清理、断链并用DevTools排查。

JavaScript 的垃圾回收（GC）是自动进行的，核心目标是识别并释放那些“不再可达”的对象所占内存。它不实时执行，而是按需或周期性触发，主要依赖标记清除（Mark-and-Sweep）算法，现代引擎（如 V8）还结合分代回收、增量回收等优化策略来减少卡顿。

垃圾回收怎么判断哪些内存该回收

关键概念是可达性（Reachability）：从一组根对象（如全局对象、当前调用栈中的局部变量、正在执行的闭包环境）出发，能通过引用链访问到的对象，就是“可达的”，会被保留；其余无法触达的对象，即被判定为垃圾。

• 函数执行结束时，其局部变量若未被外部闭包捕获，就失去可达性，可被回收
• 赋值为 null 或重新赋值，会使原引用断开，若无其他引用指向该对象，它就变成不可达
• DOM 元素被移除但仍有 JS 变量引用它，该元素仍可达，不会被 GC —— 这是常见泄漏源头

闭包与内存泄漏的关系

闭包本身不是问题，问题出在本该释放却因闭包被意外保留的引用。例如一个闭包长期持有对大型数据结构或 DOM 节点的引用，而这些数据实际已无需使用：

• 多个函数共享同一词法环境时，只要其中任一函数仍活跃，整个环境（含所有变量）都无法被回收
• 定时器回调、事件监听器中形成的闭包，若未手动清理，会持续持有对外部作用域的引用
• 常见例子：绑定事件后未解绑，且回调中引用了大数组或整个组件实例

避免内存泄漏的实用做法

重点不在“写得完美”，而在及时切断不必要的引用链：

• 事件监听器要配对移除：用 addEventListener 后，记得在合适时机（如组件卸载）调用 removeEventListener；或使用一次性监听器（{ once: true }）
• 清除定时器：setInterval 或 setTimeout 的 ID 应保存并在不需要时用 clearInterval/clearTimeout 清理
• 避免在循环中定义函数：每次迭代都新建函数实例，可能造成重复闭包和冗余引用
• 显式解除大对象引用：如缓存对象、大型数组，在确认不用后设为 null 或从容器中删除
• 警惕 DOM 引用残留：移除节点前，先解绑其事件、清空子节点引用、断开父级关联（如 parentNode.removeChild 后再置空变量）

辅助排查手段

仅靠经验不够，要用工具验证：

• Chrome DevTools 的 Memory 面板：录制堆快照（Heap Snapshot），对比不同操作前后对象数量变化，筛选“Detached DOM tree”或重复增长的构造函数实例
• 使用 Performance 面板 录制运行过程，观察内存曲线是否持续上升且不回落
• 代码中可阶段性调用 gc()（仅限 V8 命令行调试模式），强制触发 GC 辅助测试，但生产环境不可用