JavaScript垃圾回收通过可达性判断内存是否该回收：从根对象出发能访问到的对象被保留，否则被回收；闭包、事件监听器、定时器等易导致意外引用而泄漏；需主动解绑、清理、断链并用DevTools排查。
JavaScript 的垃圾回收（GC）是自动进行的，核心目标是识别并释放那些“不再可达”的对象所占内存。它不实时执行，而是按需或周期性触发，主要依赖标记清除（Mark-and-Sweep）算法，现代引擎（如 V8）还结合分代回收、增量回收等优化策略来减少卡顿。
垃圾回收怎么判断哪些内存该回收
关键概念是可达性（Reachability）：从一组根对象（如全局对象、当前调用栈中的局部变量、正在执行的闭包环境）出发，能通过引用链访问到的对象，就是“可达的”，会被保留；其余无法触达的对象，即被判定为垃圾。
- 函数执行结束时，其局部变量若未被外部闭包捕获，就失去可达性，可被回收
- 赋值为
null或重新赋值，会使原引用断开，若无其他引用指向该对象，它就变成不可达 - DOM 元素被移除但仍有 JS 变量引用它，该元素仍可达，不会被 GC —— 这是常见泄漏源头
闭包与内存泄漏的关系
闭包本身不是问题，问题出在本该释放却因闭包被意外保留的引用。例如一个闭包长期持有对大型数据结构或 DOM 节点的引用，而这些数据实际已无需使用：
- 多个函数共享同一词法环境时，只要其中任一函数仍活跃，整个环境（含所有变量）都无法被回收
- 定时器回调、事件监听器中形成的闭包，若未手动清理，会持续持有对外部作用域的引用
- 常见例子：绑定事件后未解绑，且回调中引用了大数组或整个组件实例
避免内存泄漏的实用做法
重点不在“写得完美”，而在及时切断不必要的引用链：
立即学习“Java免费学习笔记（深入）”；
-
事件监听器要配对移除：用
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 辅助测试，但生产环境不可用
