javascript的垃圾回收机制是什么_如何避免常见的内存泄漏？

JavaScript垃圾回收采用标记-清除算法：先从根对象递归标记可达对象，再清除未标记的不可达对象；常见泄漏原因包括意外全局变量、未清理事件监听器、未清除定时器、闭包过度捕获和DOM引用残留。

JavaScript 的垃圾回收（GC）机制是引擎自动管理内存的核心能力，它不依赖开发者手动释放，而是通过识别“不可达对象”并回收其占用内存来维持运行时健康。当前所有主流引擎（如 V8、SpiderMonkey）都采用 标记-清除（Mark-and-Sweep） 作为基础算法，而非早期已被淘汰的引用计数——后者无法处理循环引用，极易引发内存泄漏。

标记-清除是怎么工作的？

整个过程分两步：

• 标记阶段：从根对象（如全局对象 window 或 global、当前执行栈中的变量、活跃 DOM 节点等）出发，递归追踪所有能被访问到的对象，并打上“活跃”标记；
• 清除阶段：扫描整个堆内存，回收所有未被标记的对象——这些就是真正“不可达”的垃圾。

这个机制天然能处理循环引用问题。比如两个对象互相引用但外部已无任何引用，它们在标记阶段不会被触及，最终会被一并清除。

哪些操作容易导致内存泄漏？

虽然 GC 自动运行，但若代码中存在隐式强引用，就会让本该被回收的对象“卡住”。常见高发场景包括：

• 意外的全局变量：忘记用 let/const 声明变量，导致它挂载到 window（浏览器）或 global（Node.js）上，长期驻留；
• 未清理的事件监听器：DOM 元素被移除后，若仍通过 addEventListener 绑定着监听函数，且该函数闭包内持有对该元素的引用，元素就无法被回收；
• 定时器未清除：setInterval 或 setTimeout 的回调函数若引用了外部大对象，而定时器未被 clearInterval/clearTimeout 清理，该对象将一直存活；
• 闭包过度捕获：内部函数无意中保留了对外部大型数组、缓存对象甚至整个 DOM 树的引用，且该函数生命周期很长（如作为事件处理器长期存在）；
• DOM 引用残留：JS 中保存了对已从文档中移除的节点的引用（例如缓存在变量或 Map 中），节点及其子树都无法释放。

怎么有效防范内存泄漏？

关键不是“阻止 GC”，而是“减少不必要的强引用”。实用建议如下：

• 始终启用 "use strict"，避免隐式全局变量；
• 在组件卸载、页面跳转或模块销毁前，显式调用 removeEventListener 和 clearInterval / clearTimeout；
• 对需长期存在的回调，考虑使用 WeakMap 或 WeakSet 存储关联数据——它们不阻止键/值被回收；
• 闭包中只引用真正需要的最小数据，用完后可主动设为 null（尤其针对大型对象或 DOM 节点）；
• 借助 Chrome DevTools 的 Memory 面板做 Heap Snapshot 对比，定位持续增长的对象类型和引用链。

不复杂但容易忽略：内存泄漏往往不是单点错误，而是多个弱引用叠加的结果。保持引用意识，配合工具验证，就能让应用长时间稳定运行。