现代JavaScript引擎使用标记-清除算法，从根对象出发标记可达对象，循环引用对象若不可达则被回收；内存泄漏主因是循环结构被全局变量、闭包、事件监听器等意外持久引用。
JavaScript 的垃圾回收机制（GC）能自动处理循环引用对象，现代引擎（如 V8）使用标记-清除（Mark-and-Sweep）算法，不再受早期引用计数法的限制，因此循环引用本身不会导致内存泄漏。
为什么循环引用在现代 JS 中通常不造成泄漏
早期浏览器（如 IE6–8）用引用计数来管理内存，两个对象互相引用会导致引用数始终 ≥1，无法释放。但当前所有主流引擎（V8、SpiderMonkey、JavaScriptCore）都采用基于可达性的标记-清除算法：GC 从根对象（全局变量、调用栈中的局部变量等）出发，标记所有能访问到的对象；未被标记的，即使存在内部循环引用，也会被回收。
哪些情况仍可能引发内存泄漏
循环引用不是问题，但若循环结构意外地被外部“根”持续持有，就会阻止整个子图被回收。常见场景包括：
- 全局变量或闭包意外保留引用：比如把 DOM 元素和事件处理器存进全局对象，而处理器又引用了该元素
-
未清理的事件监听器：绑定后未调用
removeEventListener，且监听函数捕获了外部对象 -
定时器中闭包引用大对象：
setInterval回调长期存活，并持有对大型数据结构的引用 - 缓存未设上限或未清理：Map/Set 缓存对象后忘记删除，且键值形成闭环（如对象 → Map → 对象）
如何验证和排查循环引用相关泄漏
借助浏览器开发者工具可定位真实泄漏点：
立即学习“Java免费学习笔记（深入）”；
- 在 Memory 面板中录制堆快照（Heap Snapshot），筛选构造函数或关键词，对比多次快照中对象数量是否持续增长
- 查看对象的 Retainers 列表，找到阻止其被回收的引用链（例如 “Window → cacheMap → userObj → element”）
- 使用
console.memory监测堆占用变化，配合强制 GC（DevTools 中点击垃圾箱图标）观察是否回落
编写更安全的代码习惯
主动切断不必要的引用，降低 GC 压力并提升可预测性：
- DOM 元素移除前，手动解绑事件：
element.removeEventListener(...)或使用一次性监听器（{ once: true }） - 定时器结束时及时清除：
clearTimeout/clearInterval，尤其在组件卸载（如 React 的useEffect cleanup）时执行 - 缓存类使用
WeakMap/WeakSet：它们不阻止键对象被回收，天然避免因缓存导致的泄漏 - 避免将大对象挂载到全局或长期存活的模块级变量上；必要时显式置为
null
不复杂但容易忽略——关键不在循环本身，而在它是否被根路径无意锚定。
