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仍持引用，整个子树无法回收

辅助验证与日常预防

单靠快照不够直观，可叠加其他手段交叉确认：

• 在Performance面板开启Memory录制，操作前后观察JS Heap曲线：如果多次操作后内存只升不降，基本锁定泄漏
• 临时加监控：console.log(performance.memory?.usedJSHeapSize)，注意该API仅Chrome支持，适合开发阶段粗筛
• 框架项目中，确保在beforeUnmount（Vue）或componentWillUnmount（React class）里清理定时器、事件、Observer实例
• 替代方案优先用WeakMap/WeakSet缓存关联数据——它们不阻止垃圾回收，天然防泄漏

不复杂但容易忽略。真正的问题往往不在技术多难，而在“以为它自己会消失”的那一瞬间。