写前端的人多多少少都遇到过这种诡异情况页面刚打开时很流畅操作十几分钟之后开始卡顿滚动像在拖泥带水切个Tab要等两秒。打开任务管理器一看浏览器内存占用已经悄悄爬到了几百MB而且还在稳定增长。这种“页面越用越慢、内存只涨不跌”的现象十有八九和事件监听器泄漏有关。你可能会觉得奇怪不就是addEventListener加了个监听吗组件销毁了监听器不也跟着没了吗真有这么简单就不会有“内存泄漏”这个词了。事件监听器之所以会成为泄漏重灾区是因为它牵扯到JS的引用链、DOM节点的生命周期、闭包的特性还有框架里useEffect或生命周期钩子的执行时机。任何一个环节没做对监听器就会像狗皮膏药一样粘在内存里把本该释放的变量、DOM节点、组件状态全都拽住不放。这篇内容我按“原理 - 实操 - 排查 - 案例 - 工程化治理”的顺序整理覆盖原生JavaScript、React、Vue里事件监听的正确销毁方式以及用Chrome DevTools定位泄漏的具体手段。不管你是刚入行的新人还是已经写了几年业务代码的老手只要能照着把项目里的监听器清理逻辑过一遍内存曲线基本就能稳定下来。1. 为什么一个addEventListener就能把页面拖垮1.1 监听器不是“挂在元素上”而是一条顽固的引用链很多人对事件监听器有个错误认知认为监听器是DOM元素自带的功能元素销毁了监听器自然也销毁了。真实情况是addEventListener做的事情是把你的回调函数和元素绑定起来但这段关系的存续取决于回调函数是否还被其他位置引用着。举个例子你在页面上创建了一个div然后给它绑定了click监听器。后来又创建了一个弹窗组件弹窗里监听了window.resize。当你关闭弹窗并把弹窗的DOM移除时如果resize的监听器没有被移除那么这个监听器依然存活在window对象上。问题在于这个resize回调函数很可能通过闭包引用了弹窗里的DOM、状态数据那这整条链——window - 监听器 - 闭包变量 - 弹窗DOM——就全部无法被垃圾回收。结果就是弹窗关闭之后那一堆早已看不到的内存还在那杵着占着地方。这里最反直觉的点是DOM节点被移除了并不代表它被回收了。只要有JS对象还引用着它它就一直在内存里躺着。事件监听器就是最常见的“隐形引用者”。1.2 闭包把一堆变量死死拽住监听器成了“非分页缓冲池”顺带说一个这几天技术群里聊到的热词——win11分页缓冲池和非分页缓冲池内存泄漏。这个名词本身是Windows系统内核层面的问题非分页缓冲池表示内存中常驻物理内存、不可换页到磁盘的那部分一旦泄漏系统内存会持续紧张。事件监听器造成的前端内存泄漏本质上也有点“非分页”的意思你清理不掉的监听器会把一堆对象固定在内存里它们永远不会被GC扫描释放除非整个页面销毁。这种“常驻不释放”的特性和闭包的机制强相关。比如function init() { const bigData new Array(100000).fill(x); window.addEventListener(scroll, function() { console.log(bigData.length); }); } init();这个scroll回调虽然没有直接使用bigData但它定义在init作用域内闭包天然引用着bigData。即使init早就执行完毕这个监听器在window上存活着就意味着bigData也无法释放。100万个字符串可能不算夸张但你在真实项目里一个地图组件、一个表格组件、一个图表实例动辄几十上百MB的数据全被一个没清理的scroll监听器攥在手心就问你怕不怕。1.3 每次render都重新绑定泄漏就翻倍增长更麻烦的情况是框架场景。React组件每次render函数组件体都会重新执行如果useEffect的依赖数组写得不对或者压根没写cleanup那就相当于每次render都往window上挂一个新的监听器。旧的没去掉新的又来了内存呈翻倍趋势增长。页面开得越久、操作越频繁内存涨得越快最终直接白屏或者崩溃。所以核心结论很简单监听器要销毁不是“建议做”而是“必须做”。销毁的本质就是切断引用链让GC能正常回收该回收的一切。2. 监听器销毁实操从原生JS到框架最佳实践2.1 原生JavaScriptremoveEventListener的三个致命细节原生环境里移除监听器最基础的方式是function handleClick() { console.log(clicked); } const button document.getElementById(btn); button.addEventListener(click, handleClick); // 合适时机移除 button.removeEventListener(click, handleClick);看起来很简单但里面有三个细节踩坑率极高。第一个细节回调函数必须是同一个引用。addEventListener和removeEventListener传的参数需要是同一个函数对象。如果你添加监听器时用的是匿名函数后面removeEventListener时又写一个一模一样的匿名函数那是无效的——它们的内存地址不同。解决方式是先把函数抽出来命名。如果你需要传参数可以用bind或者包装一层但一定要把这个包装后的函数存下来不能每次现造。第二个细节第三个参数必须一致。addEventListener的第三个参数如果传的是true捕获阶段removeEventListener也必须传true否则移除不了。如果用options对象比如{ capture: true }那移除时也同样要传{ capture: true }。很多人只传了函数名第三个参数漏了监听器就一直残留在元素上。还有一个容易忽略的{ passive: true }这个选项只影响行为不影响绑定/解绑的匹配但capture会影响。第三个细节on属性的事件绑定要用on方式解绑。有些人习惯用element.onclick handler这种方式那清理时就要用element.onclick null而不是removeEventListener。两者是互不相干的体系混用会导致监听器清不掉。这里分享一个我在生产环境里用得很顺手的封装思路把“绑定”和“解绑”职责收敛到一个函数里function addListener(target, type, handler, options) { target.addEventListener(type, handler, options); return () target.removeEventListener(type, handler, options); } // 使用 const removeResizeListener addListener(window, resize, onResize); // 需要销毁时 removeResizeListener();返回一个解绑函数的好处是调用方不需要记住target、type、handler、options这些细节只要在生命周期结束时执行一下就可以了——对接React/Vue的销毁钩子非常自然。2.2 ReactuseEffect的cleanup才是亲儿子React函数组件里最标准的写法应该长这样import { useEffect } from react; function useScrollPosition() { useEffect(() { const handleScroll () { setScrollY(window.scrollY); }; window.addEventListener(scroll, handleScroll); return () { window.removeEventListener(scroll, handleScroll); }; }, []); }useEffect返回一个清理函数这个返回函数会在组件卸载时执行。只要你规范地写cleanup监听器就会在组件销毁时被移除。三个高频踩坑点提醒一下坑一handler不是同一个引用。如果你把handler定义在useEffect外面但useCallback没用对或者干脆没记那每次render都会生成一个新函数。addEventListener用第一版的handlerremoveEventListener用第二版的handler等于没移除。解决方案有两个把handler定义在useEffect里面这个最简单依赖了状态也没关系或者配合useCallback把handler和依赖数组都整明白再放上面去。坑二依赖数组不能乱写。如果你依赖数组里放了一些经常变化的值比如某些props、某些上下文状态那这个useEffect就会频繁重跑。每重跑一次就会先执行cleanup再重新绑定这本身没问题——前提是你cleanup写对了。如果你忘了写return清理那每次依赖变化、每次重跑都会额外挂一个新的监听器你又只挂不摘就只能等系统自然崩溃了。坑三React StrictMode的double effect。React 18的StrictMode在开发模式下会刻意将effect执行两次组件挂载 - 效果运行 - 清理 - 效果再运行。这是为了帮你检查cleanup逻辑是否健全。如果你在cleanup里没有正确地移除监听器开发环境下打开控制台就能看到监听器数量异常翻倍。这其实是好事相当于开发阶段就给你做了趟体检。2.3 VueonBeforeUnmount里的事情别等路由跳了才想起来Vue的事件监听器场景主要集中在mounted里绑定、beforeUnmount里解绑script setup import { onMounted, onBeforeUnmount } from vue; function handleScroll() { // ... } onMounted(() { window.addEventListener(scroll, handleScroll); }); onBeforeUnmount(() { window.removeEventListener(scroll, handleScroll); }); /script如果你用的是Options API就在mounted和beforeDestroyVue2或beforeUnmountVue3里做对应处理。很多写Vue的人容易漏掉一件事组件里监听了window/document上的事件但以为组件unmount了就会自动清掉实际上根本不会。Vue只会帮你解绑模板指令里自动绑定的事件比如click这种因为它们走的是Vue自己的事件系统。你手动写到window上的、document上的Vue看不见只能自己负责。2.4 有一定工程复杂度时直接上AbortController如果你觉得每次都要手动记录handler引用太麻烦有个更彻底的方法——利用AbortController现代浏览器全支持了const controller new AbortController(); window.addEventListener(resize, handleResize, { signal: controller.signal }); document.addEventListener(click, handleClick, { signal: controller.signal }); button.addEventListener(mouseover, handleMouseover, { signal: controller.signal }); // 统一销毁 controller.abort();一次abort所有传了同一个signal的监听器全部移除。这对多监听器场景特别好用你不用挨个记handler名字、挨个removeEventListener。在React里配合useEffect也很丝滑useEffect(() { const controller new AbortController(); const signal controller.signal; window.addEventListener(scroll, handleScroll, { signal }); window.addEventListener(resize, handleResize, { signal }); return () controller.abort(); }, []);一个注意点signal是一次性的abort之后这个controller就不能再复用了需要重新new一个。所以不要把这个controller提到组件外面做全局复用。另外因为AbortController在监听器解绑上确实方便我的项目里新写的代码基本都用这种方式老代码也逐步迁移过去了实测下来是真省心。3. 用DevTools揪出内存泄漏元凶3.1 从“游离DOM节点”入手最直接的方式是Chrome DevTools的Memory面板旧版本叫Profiles做一次Heap Snapshot堆快照。打开DevTools - Memory - Heap snapshot - 点击Take snapshot。拍一张快照然后在页面上执行“打开弹窗 - 关闭弹窗”这样的操作再拍第二张重复几次后拍第三张。在快照里搜索关键字detached就会看到Detached DOM节点。Detached DOM节点就是已经从页面移除但由于JS引用还被悬空挂着的DOM。如果这些节点数量在每次开关弹窗后持续增加就说明你的组件实例确实泄漏了。展开这些节点能看到它们被哪些JS对象引用着一路点下去通常就能找到那个“幽灵监听器”。不过要提醒一句快照里看到几个Detached节点不代表一定是泄漏有一些短暂的、正在被GC处理的节点也会被捕捉到。判断标准是重复同一操作后数量是否持续增长且不回落。多拍几次对比涨了就说明有问题。3.2 用Performance看内存曲线是否“不回头”Memory面板适合看静态对象但动态活动情况建议用Performance面板。开启录制在页面上做一些常规交互比如点开几个弹窗、翻几页表格、切几次Tab操作30秒到一分钟然后停止录制。在录制的Summary面板里勾选Memory查看JS Heap那条折线图。正常的曲线应该是锯齿形的——升高是分配对象下降是GC回收起伏有规律。出问题的曲线长什么样一直往上爬爬到一个高位后几乎不降或者下降的幅度越来越小整体趋势是一条右高左低的阶梯状增长线——这种情况基本可以认定内存泄漏了。3.3 控制台的getEventListeners一秒现原形还有一个启动快、贼直观的方法在DevTools的Console面板里执行getEventListeners(window)或者getEventListeners(document.getElementById(某个元素))它会直接把这个元素上绑定的所有事件监听器全部列出来。这个方法特别适合做代码审查。你可以组件挂载前后分别看一下监听器数量挂载前有几个、挂载后有几个、卸载后再看有没有回到挂载前的数量。如果卸载后数量没降那你已经知道问题就在这个组件上。注意getEventListeners是DevTools提供的调试API只能写在控制台里跑不能写进项目代码否则会直接报错。3.4 一个简单但有效的“5次开关”检测套路我在实际排查项目泄漏时经常用一个有点“土”但非常管用的套路分享给你第一步页面加载完成控制台执行window.__listenerCount getEventListeners(window).length之类的计数逻辑先记下基础数量。第二步反复打开某个弹窗/组件再关闭重复至少5次。第三步等约10秒让GC该回收的回收再数一次监听器数量。第四步对比两个值。如果数量变多了恭喜你你的组件没清理监听器。这个方法的准确性不算百分之百因为监听器数量受很多因素影响但作为快速定位的手段效率非常高。比架一堆监控工具直观得多。4. 高频翻车现场那些让人头皮发麻的真实场景4.1 表格组件里套弹窗每开一次泄漏一截真实业务中最常见的翻车现场就是表格和弹窗的组合。表格里有一个“查看详情”按钮点击后打开一个弹窗组件弹窗组件里在mounted时监听了window的scroll事件。你连续打开、关闭10次弹窗内存就悄悄挂上了10个scroll监听器。而且这些监听器里的闭包往往还引用着每次打开弹窗时的表单数据、DOM节点导致GC想收回都收不动。我在以前的项目里排查过一个案例一个数据管理后台用户操作半个小时之后页面就卡得不行。用Heap Snapshot一看Detached节点几百个全部指向同一类弹窗组件。破案之后发现弹窗的Vue组件里写了这样一段代码mounted() { window.addEventListener(scroll, this.handleScroll); }然后只在beforeDestroy里解绑了。你觉得这没问题对吧问题是这个弹窗组件不是用v-if直接销毁的而是经手了一层自己封装的高阶组件那层高阶组件把弹窗的渲染放在了另一个路由下弹窗组件销毁的钩子压根没执行。监听器自然也就没被移除一个不落全留在window上。处理这类问题单靠写规范代码还不够你得确认组件销毁钩子真的被执行了。在cleanup逻辑里加一行console.log(listener removed)然后在控制台实测打开关闭几次看看有没有输出是成本最低的做法。4.2 scroll监听 防抖没处理好变成了“每次滚动叠一层”滚动监听是最容易泄漏的事件类型因为页面全局都涉及滚动而且滚动频率极高。有些同学给window绑定scroll监听器时还做了防抖比如const onScroll debounce(handleScroll, 300); window.addEventListener(scroll, onScroll);到了销毁的时候他们写的是window.removeEventListener(scroll, handleScroll);注意这里removeEventListener传的是handleScroll而不是防抖包装后的onScroll——当然移除不掉。这个case的本质仍然是“回调函数引用不一致”但因为多了debounce这层包装更容易被忽略。小心使用防抖/节流库时你绑定的是包装后的函数解绑也必须用它原函数已经不算数了。4.3 React StrictMode下监听器数量翻倍差点误判成队友的锅React 18之后默认开StrictMode这在开发模式会对effect跑两次“挂载 - 清理 - 挂载”。如果你的useEffect里没写cleanup或者cleanup里移除监听器时handler引用对不上就会出现一个很有意思的现象打开页面控制台的日志正常但监听器数量已经是预期的两倍每次热更新还可能继续翻倍。有一次排查一个同事提交的模块我看他的代码useEffect(() { const handler () console.log(scrolling...); window.addEventListener(scroll, handler); }, []);我让他补上清理逻辑时他一开始还不理解觉得“组件又没卸载干嘛要清理”。但StrictMode会强制模拟卸载再挂载所以这会在开发环境立刻暴露问题。顺手也要检查你的handler引用是否稳定如果handler在组件内被重新定义但useCallback依赖数组没写对那照样会有残留。4.4 全局事件总线绑定的地方写了销毁的地方查无此人一些中后台项目会用EventEmitter或者mitt这类库自己维护一个全局事件总线用于非父子组件通信。在组件里通过eventBus.on(xxx, handler)绑定事件但组件销毁时忘了eventBus.off(xxx, handler)这就和事件监听器泄漏一个性质。而且这比原生addEventListener更隐蔽因为事件总线对象通常在window上挂着不销毁那上面绑的事件只能有去有回没有别的出路。用mitt时注意它的off方法格式比如import mitt from mitt; const emitter mitt(); // 绑定 emitter.on(update, handleUpdate); // 解绑 emitter.off(update, handleUpdate);mitt 3.x的off还支持off(*)这种清空所有事件的写法但项目里不建议这么搞容易误伤别的模块还是老老实实按事件名handler精确解绑。4.5 Observer们也能泄漏别只盯着EventListener严格来说ResizeObserver、MutationObserver、IntersectionObserver也会造成类似内存泄漏的问题因为它们本质上也是“长期的监听关系”。很多人在代码里new了个ResizeObserver在组件销毁时压根没调用resizeObserver.disconnect()元素虽然销毁了但observer依旧持有着对元素或回调的引用。把这些归到一起建议统一管理useEffect里创建的所有Observer、所有定时器、所有事件监听器全部在cleanup里处理一遍。我习惯写一个自定义hook把所有需要清理的东西打包进去而不是在useEffect和其他生命周期钩子里东一个西一个地散落。5. 工程化治理把“销毁监听器”变成项目默认习惯5.1 先立一条“不要全局裸挂监听器”的代码规范最简单却最有效的治理方式是在项目里明确一个约定不要在组件外部、生命周期外部裸写addEventListener。窗口级、文档级的监听器必须放在生命周期钩子里配好销毁逻辑。如果多个组件都要监听window.scroll可以考虑把监听器提到一个共享的hook里让这个hook负责统一注册和统一销毁。React的实践可以这样封装function useWindowEvent(type, handler, options) { useEffect(() { window.addEventListener(type, handler, options); return () window.removeEventListener(type, handler, options); }, [type, handler, options]); }这样每个组件只需要调useWindowEvent(scroll, handleScroll)销毁逻辑已经被封装在hook内部就不会出现“只绑不卸”的情况。Vue里也可以用composable函数做类似事情把onMounted/onBeforeUnmount的绑定清理逻辑收敛进一个函数里。5.2 事件委托能一口气解决一整片区域的监听器比逐个绑定更省心的方案是事件委托。把监听器绑在父容器上通过事件冒泡判断实际响应者。比如一个列表里有100个子项你不需要每个子项都监听click只需在列表容器上监听一次click根据event.target判断要处理的元素。这个监听器跟容器同生命周期容器销毁时它随之消失既不会有“子项销毁但监听器残留”的隐患又减少了监听器数量。代码示意// 不用这样每个item都绑监听 items.forEach(item item.addEventListener(click, handleItemClick)); // 用这样容器统一代理 listContainer.addEventListener(click, (event) { const item event.target.closest(.item); if (item) { handleItemClick(item, event); } });事件委托的注意点在事件处理的准确性比如防止点到了子元素内部、防止覆盖其他事件但这些在实际业务里都可以复健。对于表格、列表、卡片这类高频且结构和数量频繁变化的位置事件委托基本是消除监听器泄漏的治本手段。5.3 某些依赖第三方SDK的实例销毁实例时要顺带销毁监听项目中可能涉及地图SDK高德、百度、富文本编辑器如Quill、WangEditor、图表库如ECharts等等。这类第三方库往往在内部会往window或document上挂监听器用于处理鼠标移动、键盘事件、窗口尺寸变化等。当你销毁组件时如果只是把DOM从页面移除而不调用SDK提供的destroy/dispose方法它内部注册的监听器很可能一直挂在全局。最气人的是这种泄漏你从自己写的代码里根本看不出来SDK封装在node_modules里成了黑盒。建议在业务代码里强制约定凡是创建了第三方实例的组件销毁钩子必须调用该实例的销毁方法而不是仅仅移除DOM节点。比如ECharts的chart.dispose()、Quill的quill.destroy()、地图实例的map.destroy()。不确定某个库有没有这么个方法时去翻它文档里的“销毁实例”条目总比在DevTools里一个个排查来得快。5.4 给项目加一道“内存体检”环节最后我建议把内存检查写进发版前的自测列表。不需要多复杂至少每轮迭代里抽出5分钟用前面说的Performance录音跑一遍核心页面交互看看JS Heap曲线是不是只涨不降。如果发现曲线不对劲第一时间查Detached节点顺着引用链找到泄漏源再补上对应的清理逻辑。我见过不少项目平时功能测得好好的一上线跑小白鼠用户页面越用越卡用户骂声不断。内存泄漏这个问题平时注意不到一旦爆发就是事故级别。与其到时候加班排查不如把“监听器销毁”这个简单的习惯写进团队约定里写进代码模板里写进code review的必查项里。代码层面能在生命周期钩子里多写两行清理逻辑后面就少好几个通宵。我在自己项目里把这件事沉淀成了一套固定的模板每写一个需要全局监听的组件第一行想的是“怎么绑定”第二行想的是“什么时候解绑”。这个习惯改过来之后内存泄漏相关的线上问题我这边已经很久没遇到过了。