排查内存泄漏需确认监听器是否在对应时机被移除，而非仅检查是否调用removeeventlistener；典型表现为页面反复切换时内存阶梯上升、堆快照中eventlistener持续增加、detached dom节点挂载未释放监听函数。
排查事件监听未注销导致的内存泄漏，核心是确认“监听器是否在对应时机被移除”，而不是只看有没有写removeEventListener。很多问题出在绑定和解绑不匹配、生命周期错位或回调函数不一致上。
先看典型表现
页面反复进入/退出某个模块（比如弹窗打开关闭、路由切换），内存占用阶梯式上升；DevTools 中堆快照里EventListener数量持续增长；Detached DOM 节点旁总挂着一堆未释放的监听函数。
用 Memory 面板抓证据
操作前先手动触发垃圾回收（点小垃圾箱图标），再拍堆快照；执行几次目标操作后，再 GC + 拍新快照；切到 Comparison 视图，筛选 “# New” 列明显增加的 EventListener 或 (closure)。
- 右键某条目 → “Reveal in Summary view”，看它所属的构造函数和 Retaining Tree
- 顺着引用链往上找，大概率会看到类似
window.addEventListener绑定的匿名函数，或某个组件实例的 methods 方法被长期持有 - 特别注意：如果看到
HTMLDivElement → EventListener → closure → ComponentInstance这类路径，基本锁定是组件销毁后监听器没清
检查代码里的常见陷阱
不是写了 removeEventListener 就安全，关键看它能不能真正执行、参数是否对得上：
- 用箭头函数绑定事件 → 解绑时传入的不是同一个函数引用（箭头函数每次都是新实例）
- 在 Vue 的
beforeUnmount或 React 的useEffect cleanup里漏写解绑逻辑 - 全局监听（如
window.resize）绑在 mounted，却在 destroyed 里忘记解 - 第三方库封装的事件（如 Map SDK 的
on('click', handler)）没调用对应off或removeListener
修复要落实到具体动作
不能只靠“意识”，得有可验证的清理机制：
- 优先用
{ once: true }绑定一次性事件，避免后续管理 - 监听器统一定义为组件内方法（非箭头函数），确保 add 和 remove 传同一引用
- Vue 中在
beforeUnmount显式调用removeEventListener；React 中在useEffect返回函数里清除 - 复杂场景下，把监听器存到实例属性（如
this.resizeHandler = () => {...}），销毁时统一清理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
