根本原因是removeEventListener必须传入与addEventListener时完全相同的函数引用；匿名函数每次声明都生成新对象，导致===判断为false，无法匹配移除。
匿名函数导致 removeEventListener 完全失效
根本原因不是“写法错”，而是 JavaScript 强制要求 removeEventListener 必须传入与 addEventListener 时**完全相同的函数引用**。匿名函数每次声明都会生成新对象，哪怕内容一模一样，=== 判断也是 false。
典型失效写法：
btn.addEventListener('click', () => console.log('hi'));
btn.removeEventListener('click', () => console.log('hi')); // ❌ 不匹配，监听器还在
这种写法不会报错，但也不会移除——监听器持续驻留，绑定的闭包（比如外层变量、DOM 元素）无法被 GC 回收。
capture 或 options 不一致也会让 remove 失效
即使函数引用对上了，removeEventListener 还要求第三个参数（options）必须是同一个对象引用，而不是“属性相同”的新对象。
-
{ capture: true }和{ capture: true, passive: false }是两个不同对象，不能互换 -
element.removeEventListener('scroll', fn, { capture: true })无法移除用const opts = { capture: true }; addEventListener(..., opts)添加的监听器 -
once: true的监听器触发后自动清理，但若想提前取消，仍需用完全相同的options对象调用removeEventListener
内存泄漏的真实表现不是卡顿，而是对象滞留
泄漏不总在几秒内显现，但长期积累会拖垮单页应用：
- 组件卸载后，其内部定义的箭头函数仍绑在
window或document上，整个组件实例无法释放 - 列表项循环绑定
item.addEventListener('click', () => handleClick(item.id))，每个() => ...都捕获了item，哪怕 DOM 被删，这些函数+闭包仍在内存里 - Node.js 中
EventEmitter持续添加匿名回调，emitter.listenerCount('data')会不断上涨，最终触发MaxListenersExceededWarning
AbortController 是现代解法，但要注意 signal 复用限制
ES2021 起支持 { signal } 选项，靠 controller.abort() 清理，绕开函数引用难题：
const controller = new AbortController();
btn.addEventListener('click', () => console.log('ok'), { signal: controller.signal });
// 后续任意时刻
controller.abort(); // ✅ 立即移除
关键约束：
- 一个
AbortController的signal只能用一次 ——abort()后再传给新addEventListener会抛AbortError - 不能跨多个事件共用同一个
signal并期望只 abort 其中一部分；如需分组控制，得为每组新建controller - 旧版浏览器（如 IE、老 Android WebView）不支持，需降级 fallback 到具名函数 + 手动管理
真正容易被忽略的是：signal 不是“开关”，而是一次性令牌。它解决了引用匹配问题，但没解决“何时 abort”这个业务逻辑问题——你仍得自己决定清理时机，并确保 controller 实例不被意外丢弃或重复 abort。
