JavaScript内存泄漏检测主要靠Chrome DevTools的Memory和Performance面板配合人工分析，核心是“对比变化、定位异常、追溯引用”，常见于未解绑事件监听器、未清除定时器、意外全局变量、闭包长期持有大对象、DOM被JS强引用五类高频场景。
JavaScript内存泄漏检测主要靠Chrome DevTools的Memory和Performance面板配合人工分析，核心是“对比变化、定位异常、追溯引用”。常见泄漏场景集中在几类典型编码疏漏，不是所有闭包或定时器都会泄漏，关键看引用是否被意外长期持有。
用Chrome DevTools快速定位泄漏
打开F12 → Memory面板 → 按以下顺序操作：
- 点击“Take heap snapshot”拍下初始快照（Baseline）
- 执行可疑操作（如打开/关闭弹窗、切换路由、反复渲染列表）
- 再次拍快照，切换到“Comparison”视图，筛选“# New”列明显增长的构造函数（如
Closure、Array、Object） - 重点关注
Detached DOM tree：表示DOM节点已从页面移除，但仍有JS变量在引用它 - 双击可疑对象，查看右侧“Retaining Tree”，顺着引用链找到谁在“拽住”它不放
5种高频泄漏场景及表现
这些不是理论风险，而是线上真实高频问题：
-
未解绑的事件监听器：元素被
remove()后，addEventListener没配对调用removeEventListener，回调函数连带其闭包作用域无法回收 -
忘记清除的定时器：用
setInterval轮询数据时，组件卸载后定时器仍在运行，持续持有DOM引用或大数组 -
意外的全局变量：函数内漏写
let/const，直接赋值data = fetchData()→ 自动挂到window.data上，永不释放 -
闭包长期持有大对象：返回一个内部函数，该函数引用了外部创建的万级数组或缓存对象，且这个函数被全局变量保存（如
const keep = createHandler()） -
DOM节点被JS变量强引用：把
document.getElementById('app')存进全局Map或Vuex state，之后该DOM被innerHTML = ''清空，但JS仍持引用，整个子树无法回收
辅助验证与日常预防
单靠快照不够直观，可叠加其他手段交叉确认：
立即学习“Java免费学习笔记（深入）”；
- 在Performance面板开启Memory录制，操作前后观察JS Heap曲线：如果多次操作后内存只升不降，基本锁定泄漏
- 临时加监控：
console.log(performance.memory?.usedJSHeapSize)，注意该API仅Chrome支持，适合开发阶段粗筛 - 框架项目中，确保在
beforeUnmount（Vue）或componentWillUnmount（React class）里清理定时器、事件、Observer实例 - 替代方案优先用
WeakMap/WeakSet缓存关联数据——它们不阻止垃圾回收，天然防泄漏
不复杂但容易忽略。真正的问题往往不在技术多难，而在“以为它自己会消失”的那一瞬间。
