匿名闭包在事件监听器中无法手动解绑，是前端内存泄漏最隐蔽且普遍的诱因；它不报错不卡顿，但每次交互后内存“悄悄上涨”，久而久之引发卡顿崩溃，且难以复现。
匿名闭包在事件监听器中无法手动解绑，是前端内存泄漏最隐蔽也最普遍的诱因之一。它不报错、不卡顿，但每次页面交互或组件重建后，内存占用都会“悄悄涨一点”——久而久之，用户端卡顿、崩溃频发，而开发者却难以复现。
一眼识别：匿名监听器是否已失控
检查代码中是否存在这类写法：
element.addEventListener('click', () => { /* 逻辑 */ });-
window.addEventListener('resize', function() { ... });（未命名的 function 表达式） -
btn.onclick = () => {...};（直接赋值，无法 remove）
只要监听器是匿名函数，就永远无法被 removeEventListener 精准移除。哪怕元素已被 remove()，该闭包仍挂在 EventTarget 内部监听器列表中，持续持有其词法作用域里的所有变量（DOM 节点、state、大数组等）。
用 Chrome DevTools 快速验证泄漏链
打开 Memory 面板 → 执行三次“打开-关闭模块”操作 → 连续拍三张堆快照：
- 切换到 Comparison 视图，筛选
Closure类型，观察数量是否阶梯式上升 - 点开任一增长明显的 Closure，看 Retainers 列表：若出现
EventTarget → listener → Closure → DOM element链路，就是它 - 重点留意
Detached DOM tree数量是否同步增加——这是匿名监听器拖住 DOM 子树的铁证
运行时辅助判断：监听器是否越积越多
在疑似泄漏的模块加载后，执行：
getEventListeners(document.body)
或针对具体元素：
getEventListeners(someElement)
如果返回的 click / scroll 等事件数组长度随操作反复增加（比如从 1→3→6），说明每次绑定都新增了无法清理的监听器。
修复不是重写逻辑，而是让闭包“可卸载”
核心原则：把匿名函数变成可引用、可比对、可移除的实体：
- 改用具名函数：
function handleClick() { ... }; el.addEventListener('click', handleClick); el.removeEventListener('click', handleClick); - 用 AbortController（推荐现代写法）：
const ctrl = new AbortController(); el.addEventListener('click', handler, { signal: ctrl.signal });→ 后续调用ctrl.abort()即自动解绑全部监听器 - React 中避免 useEffect 里写匿名回调：
useEffect(() => { const h = () => {}; window.addEventListener('x', h); return () => window.removeEventListener('x', h); }, [])
不需要消灭闭包，只需要让它生命周期可控。一旦监听器能被精准清除，闭包持有的上下文自然释放，内存曲线就会回归平缓。
