addEventListener未解绑会导致内存泄漏，因回调持有外部引用使DOM及关联对象无法被GC回收；需配对使用removeEventListener、避免匿名函数、谨慎处理capture/委托/第三方库绑定，并依据明确状态信号解绑。
addEventListener 未解绑导致的内存泄漏
DOM 元素被移除后，若其绑定的 addEventListener 回调仍持有对外部变量（如闭包中的 data、component 实例）的引用，该元素和相关对象就无法被 GC 回收。
常见于单页应用中动态创建/销毁组件（比如 Vue/React 的子组件挂载时加事件、卸载时没清理）或手动操作 DOM 的场景。
- 始终配对使用
removeEventListener，且传入与绑定时完全相同的函数引用（不能是匿名函数或每次新建的箭头函数） - 推荐用具名函数或在组件类中定义方法，并在
beforeUnmount/componentWillUnmount/disconnectCallback中显式解绑 - 若需传递参数，用
bind或闭包封装后，务必保存原始函数引用以便后续解绑
const handler = () => console.log('clicked');
element.addEventListener('click', handler);
// ……卸载时
element.removeEventListener('click', handler);
使用 capture 阶段监听却忽略解绑时机
在捕获阶段（{capture: true}）绑定事件，和冒泡阶段一样会延长 DOM 节点生命周期 —— 但开发者更容易忽略它，因为视觉上“没看到”事件发生在目标上。
尤其在全局监听（如 document.addEventListener('click', ..., {capture: true})）用于菜单收起、弹窗关闭等逻辑时，若未在对应时机清除，会持续持有回调闭包，进而阻止整个模块卸载。
立即学习“前端免费学习笔记（深入）”；
-
capture和once选项互斥，不能靠once自动清理；必须手动调用removeEventListener - 全局捕获监听建议统一管理：用 Map 存储
element → handler映射，销毁前批量清理 - 避免在
document或window上长期绑定无清理机制的捕获监听
事件委托中 target 判断不严谨引发隐式引用
用 document.addEventListener('click', e => {...}) 做委托时，若回调内直接访问已销毁节点的属性（如 e.target.dataset.id），看似无害，但若该 target 是一个已被移除但仍被 JS 引用的元素（例如被父级 innerHTML = '' 清空但未触发 GC），就可能拖慢回收。
更隐蔽的问题是：回调中若把 e.target 缓存为全局变量、塞进数组、或赋给某个长期存活对象的属性，就会形成强引用链。
- 委托回调中避免将
e.target或其父元素赋值给长生命周期对象（如 class 实例属性、全局 Map） - 必要缓存时，改用
WeakMap关联 DOM 节点与数据，确保节点被移除后自动解耦 - 用
e.currentTarget替代频繁访问e.target，减少对临时节点的依赖
第三方库绑定事件后未提供清理接口
像 Chart.js、Flatpickr、Swiper 等库内部调用 addEventListener，但部分版本未暴露销毁方法，或文档未强调需手动调用 destroy()。
典型表现：切换路由后内存占用持续上升，DevTools 的 “Memory” 面板中发现大量 detached DOM 节点，且它们的 event listeners 一栏非空。
- 查阅所用库文档，确认是否存在
destroy、off、teardown类方法，并在组件卸载时调用 - 若库无清理 API，可尝试用
getEventListeners(node)（Chrome DevTools API，仅调试用）验证是否残留监听器 - 对重度依赖事件的库，考虑用
Shadow DOM隔离或 iframe 沙箱化，利用浏览器原生卸载机制兜底
真正难处理的不是「怎么绑」，而是「什么时候确定可以安全地解绑」——尤其在异步渲染、过渡动画未结束、或用户操作中途取消的边界条件下，解绑早了会丢事件，晚了就留泄漏。别依赖「应该已经完了」这种判断，得靠明确的状态信号驱动清理。
