JavaScript内存泄漏主因是对象无法被垃圾回收，V8引擎采用标记清除机制，通过根对象递归标记可达对象，未标记者被清除；常见泄漏场景包括未清理定时器、未解绑事件监听器、闭包持有DOM引用及意外全局变量，可用Chrome DevTools的Memory面板、堆快照和Performance面板检测。
JavaScript 的内存泄漏检测和垃圾回收机制是前端性能优化的关键环节。浏览器会自动管理内存，但写法不当仍会导致对象无法被回收，长期积累拖慢应用甚至崩溃。
垃圾回收机制：标记清除（Mark-and-Sweep）
现代 JavaScript 引擎（如 V8）主要采用标记清除策略：当一次垃圾回收开始时，引擎从一组“根对象”（如全局变量、当前执行函数的局部变量、调用栈中的引用等）出发，递归标记所有可达对象；未被标记的对象即为不可达，随后被清除释放内存。
注意：引用计数曾用于早期实现，但因无法处理循环引用（如两个对象互相持有对方的引用）已被主流引擎弃用。
- 闭包中意外保留对外部大对象的引用，会让该对象一直存活
- 全局变量、定时器回调、事件监听器未解绑，都会延长对象生命周期
- DOM 元素被移除后，若 JS 仍持有其引用（尤其通过闭包或缓存），它不会被回收
常用内存泄漏检测方法
借助浏览器开发者工具（以 Chrome DevTools 为例）可高效定位问题：
立即学习“Java免费学习笔记（深入）”；
- Memory 面板 + 堆快照（Heap Snapshot）：在关键操作前后分别录制堆快照，对比“Objects allocated between snapshots”，重点关注持续增长的构造函数（如 Array、Object、闭包函数名）
- Allocation instrumentation on timeline：开启后录制操作过程，实时观察内存分配热点，快速识别高频创建且未释放的对象
- Performance 面板录制 + 内存曲线：勾选 Memory 复选框，查看 JS Heap、Documents、Nodes、Listeners 数量变化；若 JS Heap 持续上升不回落，可能存在泄漏
-
Console 中使用 performance.memory（仅部分环境支持）：读取
usedJSHeapSize和totalJSHeapSize，辅助判断内存占用趋势
典型泄漏场景与规避建议
以下写法看似无害，实则容易埋下隐患：
- 未清理的定时器：`setInterval(() => { /* 引用了外部大数组 */ }, 1000)` → 使用前保存 timer ID，组件卸载/页面离开时调用 `clearInterval(id)`
- 未解绑的事件监听器：`el.addEventListener('click', handler)` → 对应地 `el.removeEventListener('click', handler)`；推荐使用 `AbortController`（现代方案）或确保 handler 是具名函数而非箭头函数
-
闭包中缓存 DOM 或大数据：避免在事件回调或定时器中长期持有 `document.getElementById(...)` 或大型 JSON 数据的引用；用完及时置为
null -
意外的全局变量：忘记写
var/let/const，如myCache = new Map()→ 直接挂到window上，永不释放
基本上就这些。检测不难，关键是养成“谁申请、谁清理”的意识，配合工具定期验证。不复杂但容易忽略。
