HTML事件监听器管理不当是前端内存泄漏最常见诱因，如addEventListener后未配对removeEventListener、箭头函数无法移除、短命组件被长存节点引用、IE循环引用等，导致闭包和DOM节点无法GC。
HTML事件本身不直接导致内存泄漏，但事件监听器的注册方式、生命周期管理不当，是前端内存泄漏最常见诱因之一。
addEventListener 后忘记 removeEventListener
这是最典型的泄漏场景：组件卸载后，监听器仍挂在 DOM 节点或 window 上，闭包持续引用着本该被回收的作用域。
- 常见错误现象：
performance.memory.usedJSHeapSize持续上涨，页面反复进入/退出后堆内存不回落 - 使用场景：单页应用中动态创建的弹窗、图表、第三方 SDK 初始化后的全局监听（如
window.addEventListener('resize', handler)） - 实操建议：所有
addEventListener都应配对removeEventListener；若用箭头函数注册，无法移除——改用具名函数或保存 handler 引用 - 示例：
function handleScroll() { /* ... */ }<br>window.addEventListener('scroll', handleScroll);<br>// 卸载时必须：<br>window.removeEventListener('scroll', handleScroll);
事件监听器绑定在长期存活节点上，却引用短命组件
比如把 React 组件方法直接传给 document.body.addEventListener，而该组件已 unmount，但 handler 仍持有 this、state、props 的引用，导致整块组件实例无法 GC。
- 参数差异：
addEventListener的第三个参数{ once: true }可避免手动清理，但仅适用于一次性事件 - 性能影响：泄漏对象越多，GC 压力越大，后续页面交互卡顿明显
- 实操建议：优先使用事件委托 + 条件判断，或在组件销毁钩子（如
useEffect cleanup、connectedCallback/disconnectedCallback）中统一解绑
IE 中 attachEvent / detachEvent 的循环引用遗留问题
虽然现代项目基本不兼容 IE，但若维护老系统，需特别注意：attachEvent 注册的 handler 若引用了 DOM 元素，又让该 DOM 元素反向引用 handler（如 elem.onclick = handler），就会形成 IE6–8 下无法被引用计数回收的循环引用。
立即学习“前端免费学习笔记（深入）”；
- 错误信息：
SCRIPT70: Permission denied或内存占用随操作次数线性增长 - 实操建议：强制解除双向引用，卸载前执行
elem.onclick = null和elem.detachEvent(...)；避免在 handler 内给 DOM 元素挂 expando 属性（如elem.customData = {...}） - 兼容性提醒：
innerHTML在 IE9–11 插入嵌套表格时也会触发同类泄漏，本质仍是 DOM-JS 循环引用未断开
真正难排查的不是“有没有监听器”，而是“监听器在哪被谁持有着”。DOM 节点被移除但未清除事件、闭包捕获了父作用域变量、第三方库内部未暴露清理接口——这些细节一旦漏掉，泄漏就藏在看不见的地方。
