JavaScript闭包：移除DOM事件时的注意事项

先说明一个容易误解的事实：闭包本身并不会阻止事件监听器被移除。真正的问题在于两个关键点——函数引用不一致和隐式强引用未断开。只要确保添加和移除事件监听器时使用的是同一个函数引用，并主动切断对DOM元素的持有，就能避免监听器残留和内存泄漏。

先拆开来看：如果事件监听器只添加不移除，确实会越积越多。但真正导致垃圾回收无法到位的，往往是下面两个细节。

必须使用同一个函数引用添加和移除

每次写 () => {} 或 function() {}，Ja vaScript 都会创建一个全新的函数对象。即使代码内容完全相同，它们在内存中也是彼此独立的对象。如果用一个匿名函数添加监听器，再用另一个长得一模一样的匿名函数执行移除——removeEventListener 根本找不到当初注册的那个。

• 错误：循环里每次新建匿名函数用于 add，但 remove 时只写一个同样的匿名函数
• 正确：提前把 handler 定义为具名函数，或者使用 useCallback（React）、fn.bind() 并保存好返回值
• 特别注意：箭头函数、bind() 调用、闭包工厂函数，每次都会返回一个新引用，不能直接用在 remove 上

闭包悄悄“拽住”已移除的 DOM

这是另一个容易忽略的问题。如果闭包直接捕获了某个 DOM 节点——比如一个按钮、一个输入框——而该节点后来被 remove() 或 innerHTML = '' 清空，只要闭包还在存活，那个 DOM 就不会被垃圾回收。即使它早已不在页面上。

• 常见高危写法：el.addEventListener('click', () => console.log(el.value)) —— 闭包持有了 el
• 修复思路：改用 e.target 获取当前点击元素；或者将 DOM 引用显式设为 null 释放
• 更稳妥的做法：使用 WeakReference 包裹 DOM（ES2023+），让 GC 可以安全回收，不受闭包影响

优先使用现代 API，减少手动清理的负担

不必在所有场景下手写 removeEventListener。浏览器和标准已经提供了更简洁可靠的方案。

• { once: true }：监听器触发一次后自动卸载，彻底规避忘记移除的风险
• { signal: controller.signal }：用 AbortController 统一控制多个监听器的生命周期，组件卸载时调用 controller.abort() 即可全部解绑
• 事件委托：父容器监听 + e.target.matches()，闭包只持有父级引用，不绑定每个子元素，自然避开批量引用残留

框架场景下务必配合生命周期清理

在 React、Vue 这类框架应用里，闭包很容易随着组件状态或 ref 存活很久。如果组件卸载了但闭包还在，就可能造成协同泄漏——多个因素一起导致内存无法释放。

• React：在 useEffect 的清理函数里移除监听器、清除定时器、重置 ref.current 属性
• Vue：在 onBeforeUnmount 或 beforeDestroy 中将闭包持有的 DOM 或 state 引用置为 null
• 还有一个容易被忽略的陷阱：不要把闭包直接挂在 DOM 的自定义属性上（比如 el.handler = fn），尤其当 fn 内部又反向引用回 el 时，极易形成循环引用