17370845950

JavaScript内存泄漏主因是垃圾回收未及时清理，因标记-清除机制仅回收不可从根（全局对象、执行上下文变量、闭包变量）访问的对象；常见泄漏模式包括定时器/事件监听器未清除、闭包意外保留大对象、全局缓存不清理、console.log残留引用、innerHTML替换未解绑及第三方库未destroy。

JavaScript 不需要手动分配或释放内存，但不意味着可以完全不管内存——真正的问题往往出在“以为它自动了，其实没自动干净”。

垃圾回收机制靠什么判断对象该清理？

主流引擎（V8、SpiderMonkey）用的是标记-清除（Mark-and-Sweep），不是引用计数。关键点在于：一个对象是否「可从根访问」——根包括全局对象、当前执行上下文中的局部变量、闭包中捕获的变量等。

• setTimeout 或 setInterval 的回调里长期持有大数组或 DOM 引用，会阻止回收
• 事件监听器没用 removeEventListener 解绑，且监听器是匿名函数时，无法手动清除引用
• 闭包意外保留对外部作用域大对象的引用（比如在内部函数里存了 document.getElementById('huge-table')）

哪些操作容易造成内存泄漏？

不是所有“没释放”的情况都叫泄漏，但以下模式在真实项目中反复出现：

• 全局变量缓存数据（如 window.cacheMap = new Map()）且从不清理
• 控制台调试时用了 console.log(largeObject) —— Chrome DevTools 会保持对对象的引用，直到清空控制台
• 使用 innerHTML 插入含事件绑定的 HTML 字符串，旧

  

  节点未解绑就替换，监听器残留
• 第三方库（如某些图表库）初始化后没调用 destroy() 方法，内部 canvas、timer、data 数组持续驻留

怎么确认是不是真有内存问题？

别猜，用 Chrome DevTools 的 Memory 面板实测：

• 录制堆快照（Heap Snapshot）前，先强制触发 GC：点击右上角 Collect garbage 图标
• 对比两次快照，筛选 Retained Size 大且增长明显的构造函数（如 Array、Object、自定义类名）
• 点开可疑对象，看 Retainers 列表——谁在引用它？是不是某个没清理的 eventListener 或 closure？
• 用 Allocation instrumentation on timeline 录制运行过程，观察新分配对象是否被及时回收

最常被忽略的一点：内存问题往往不是单个 bug，而是多个小引用链叠加的结果；排查时要顺着 retainers 往上翻三层以上，而不是只看第一级引用。