漏掉 removeeventlistener 是高频内存泄漏雷区，需检查生命周期配对、避免匿名函数绑定、警惕全局目标监听及 removeeventlistener 参数不匹配等风险。
在大厂代码评审中，漏掉 removeEventListener 不是小疏忽，而是高频内存泄漏雷区。它不会立刻报错，但会在用户反复进入/退出模块、切换路由、刷新列表时，让监听器数量指数级堆积，最终拖垮页面响应和内存占用。评审时不需要运行代码，靠几处关键信号就能快速识别风险。
看事件绑定是否出现在生命周期“入口”但无对应“出口”
重点检查组件初始化、DOM挂载、模块激活等函数（如 React 的 useEffect 第一个参数、Vue 的 mounted、类构造函数中的 init 方法）。如果里面调用了 addEventListener，必须同步检查是否存在明确的清理逻辑（如 return 的清理函数、destroy / unmount / componentWillUnmount 等钩子）。
常见危险模式：
- 只在 componentDidMount 中添加 resize / scroll / click 监听，但 componentWillUnmount 里没写任何 removeEventListener
- useEffect 依赖数组为空（[]），却没返回清理函数
- 事件绑定写在普通工具函数里，而该函数被多次调用（如表格每行渲染都执行一次），但清理逻辑只放在顶层或从未定义
查 listener 是否为匿名函数或箭头函数
只要 addEventListener 的第二个参数是 () => {...} 或 function() {...} 这类现场创建的函数，基本可判定 无法被安全移除 —— 因为每次调用都会生成新引用，removeEventListener 拿不到原始引用。
评审时直接标红并建议：
- 改用具名函数声明或 const 声明的稳定函数引用
- 若需闭包传参，改用 data 属性 + 事件委托，或把 handler 提到外层作用域缓存
- 拒绝 “先加再删” 式伪清理：比如在 destroy 里写
el.removeEventListener('click', () => {...})—— 这行代码本身无效
盯住全局/长生存期目标上的监听器
window、document、body、单例容器元素（如 #app、.main-layout）是重灾区。这些对象生命周期≈整个页面，一旦监听器漏删，就会持续驻留。
评审发现以下写法要立即追问：
-
window.addEventListener('resize', handleResize)出现在非根组件或非全局管理模块中 -
document.addEventListener('keydown', ...)在弹窗、抽屉、临时浮层中注册，但未随其关闭而移除 - 监听器绑定在通过 querySelector 获取的 DOM 节点上，而该节点后续可能被 innerHTML 清空或 replaceChild 替换，但监听器未提前解绑
注意“假清理”：removeEventListener 参数不匹配
即使写了 removeEventListener，也可能是无效的。评审时核对三要素是否完全一致：
- 事件类型（'click' vs 'mousedown'）
- listener 引用（必须是同一个函数对象）
- options/useCapture 参数（如 { capture: true } 必须成对出现）
特别警惕：
- 添加时用了
{ once: true }，但移除时没带这个 options - 添加时用了
handle.bind(this)，移除时却传了原始handle - 使用了第三方封装（如 on() / off()），但底层未保证引用一致性
不复杂，但容易忽略。
