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 面板实测：
立即学习“Java免费学习笔记（深入）”；
- 录制堆快照（Heap Snapshot）前，先强制触发 GC：点击右上角
Collect garbage图标 - 对比两次快照，筛选
Retained Size大且增长明显的构造函数（如Array、Object、自定义类名） - 点开可疑对象，看
Retainers列表——谁在引用它？是不是某个没清理的eventListener或closure？ - 用 Allocation instrumentation on timeline 录制运行过程，观察新分配对象是否被及时回收
最常被忽略的一点：内存问题往往不是单个 bug，而是多个小引用链叠加的结果；排查时要顺着 retainers 往上翻三层以上，而不是只看第一级引用。
