什么是Javascript的垃圾回收机制与内存管理？

标记-清除是V8等现代引擎唯一依赖的核心垃圾回收算法，它从根（如window、调用栈变量）出发递归标记可达对象，未被标记的循环引用对象也会被清除；常见泄漏点包括未清理setInterval、dom移除后未解绑事件监听器、闭包过度捕获及console.log隐式保留引用。

javaScript 的垃圾回收机制是引擎自动识别并释放“不可达对象”内存的过程，开发者无需手动 free，但若保留了意外引用，对象就永远不会被回收——这就是内存泄漏的根源。

标记-清除（Mark-and-Sweep）是怎么工作的？

这是 V8 等现代引擎唯一依赖的核心算法。它不看引用次数，而是从“根”出发判断可达性：

• window、globalThis、当前函数调用栈里的变量、DOM 元素引用等，都是“根”
• 引擎递归遍历所有能从根到达的对象，并打上“存活”标记
• 没被标记的对象，哪怕 obj1.ref = obj2 且 obj2.ref = obj1（循环引用），只要根访问不到，就全被清掉

这正是为什么引用计数（Reference Counting）已被淘汰：它卡在循环引用上，而标记-清除天然绕过这个问题。

哪些代码会让对象“假存活”，逃过回收？

不是 GC 失灵，是你无意中给它留了后门。常见泄漏点：

立即学习“Java免费学习笔记（深入）”；

• 忘记清理 setInterval：回调闭包里引用了大数组，定时器没 clearInterval，整个闭包就一直挂在线程上
• DOM 移除后没解绑监听器：btn.addEventListener('click', handler)，但 btn.remove() 后没配对调用 removeEventListener，handler 和它捕获的上下文全锁死
• 闭包过度捕获：function createCache() { const bigData = new Array(1e6); return () => console.log(bigData.Length); } —— 即使返回的函数根本不用 bigData，它也被强持有
• 控制台日志干扰：console.log(largeObj) 后在 DevTools 里点开查看过，chrome 可能隐式保留引用，仅开发环境需注意

怎么验证是不是真泄漏了？

别猜，用 chrome devtools 直接看证据：

• 打开 Memory 面板 → 点击 Take Heap Snapshot，操作前拍一张，反复打开关闭模块后再拍一张
• 对比两次快照，筛选 Retainers 列：找谁在引用那个本该消失的大对象（比如某个未清除的 setTimeout 回调、或挂在 window 上的缓存）
• 点 Collect garbage 按钮强制触发 GC，再看内存是否回落——如果没回落，说明还有活引用卡着

真正难的不是发现泄漏，而是搞清“谁在持有着它”。很多时候问题不在你写的逻辑里，而在第三方库绑定的监听器、或某次 console.log 后忘了收起控制台面板。