点击狂魔变幽灵？JS 事件解绑的 4 个隐形坑，别再让代码“漏电”了

做前端久了，最怕半夜被电话叫醒，不是服务挂了，而是用户反馈某个页面越点越卡，最后浏览器直接白屏。这种情况十有八九是内存泄漏，而罪魁祸首往往是那些没有解绑的事件监听器。很多同学在写 addEventListener 时很顺手，但在清理环节却容易掉以轻心，导致组件销毁后，旧的事件依然“附着”在对象上，静静等待下一次触发。

最常见的翻车现场，莫过于匿名函数的陷阱。我们习惯把回调函数直接写在监听器里，比如 btn.addEventListener('click', () => { ... })。这时候想解绑？你会发现根本找不到那个函数引用，removeEventListener 只能移除同名且同引用的函数。正确的做法是把处理函数提取出来单独命名，像这样定义一个 const handleClick = () => { ... }，在绑定和解除时都使用同一个变量名。记住：无法引用的函数，永远无法被清除。

即使函数名一致，还有一个更隐蔽的细节：上下文与参数的匹配。当你给一个普通函数绑定了特定的 this，比如 handleClick.bind(this)，每一次调用 bind 都会返回一个新的函数实例。如果你在绑定时用了一次 bind，解绑时又用了同样的代码再 bind 一次，它们依然是两个不同的函数引用，导致解绑失败。解决这个死结，要么提前存好绑定后的函数变量，要么改用箭头函数规避 this 指向问题，确保添加与移除时的函数指针完全一致。

除了函数本身，配置对象的一致性也常被忽视。从 Chrome 80 开始，removeEventListener 对第三个参数（options）有了严格校验。如果你添加时写了 { capture: true }，解绑时却漏了这个选项，或者默认值不同，浏览器会默默拒绝执行。哪怕其他条件都对得严丝合缝，捕获阶段的不匹配也会让解绑失效。建议养成习惯，将配置项统一提取为一个常量对象，确保绑定和解绑共享同一份配置，减少人为比对失误。

到了单页应用（SPA）时代，生命周期管理成了关键。在 Vue 或 React 中，DOM 元素可能随着路由切换被频繁销毁重建，但闭包中的全局引用若未切断，事件依然存活。别光依赖框架的自动清理，对于手动添加的全局监听，比如在 window 或 document 上绑定的事件，务必在组件卸载的钩子里显式调用解除方法。如果不确定清理是否彻底，可以利用 WeakMap 记录元素与事件的对应关系，在移除 DOM 节点前批量回溯清理，彻底杜绝残留。

其实，现代浏览器已经提供了更简单的方案，比如 once 选项，让监听器只触发一次后自动注销，减少了手动管理的麻烦。但对于需要重复交互的场景，规范的写法依然是基本功。写代码是为了让人维护，也是为了让机器运行更高效。 做好事件解绑，不仅是防止内存泄漏的技术手段，更是体现工程师职业素养的细节所在。下一次重构旧项目时，不妨检查一下那些沉睡的监听器，别让它们在后台悄悄吞噬系统的资源。