如果让我从 JavaScript 的所有知识点里选一个“学完立刻能改变代码质量”的，我会选事件处理。不是因为它难，而是因为它几乎贯穿所有交互场景：点击按钮要响应、滚动页面要优化、键盘输入要校验、异步请求完成后要更新界面……这些动作背后，全是事件在驱动。这是《JavaScript学习手册》系列的第十五篇，前面我们已经把数据类型、对象、数组、循环、条件判断、字符串、函数这些基础都过了一遍，现在到了真正“用户触碰页面”的环节，把事件处理讲透，后面的框架学习和实战项目才能不心虚。
这篇文章不会只罗列 addEventListener 怎么用，我会从事件流模型、事件对象的隐藏细节、事件委托、性能优化、实战坑点这几个维度讲，目标是让你看完之后，遇到任何交互需求都能有自己的排查思路，而不是靠“试一下能不能行”来写代码。无论你是刚学完基础的前端新人，还是已经写过不少页面、但对事件底层机制还比较模糊的同学，这篇都值得你静下心读一遍。
1. 事件处理的核心设计思路：先建立事件流心智模型
1.1 事件三阶段：捕获、目标、冒泡到底在说啥
很多同学写了半年前端，问“事件冒泡是什么”能答上来，但问“事件捕获在什么场景下有用”就卡住了。这其实不是概念记不住，而是没有在脑子里建立事件流的“心智模型”。
浏览器里的 DOM 是树状结构，一个事件从触发到结束，会经历三个阶段：捕获阶段（从 window 一路向下到目标元素）、目标阶段（事件到达真正触发的元素）、冒泡阶段（从目标元素一路向上回到 window）。我习惯用一个快递派送的类比来解释：捕获是快递车从总站出发，沿着街道往你家这条分支逐级派送；目标阶段就是快递员敲响你家门；冒泡阶段是你签收之后，这个“签收记录”又沿原路逐级报告回去。
为什么要理解这个流程？因为事件监听的触发顺序完全由它决定。如果你在父元素和子元素上都绑定了点击事件，点击子元素时，父元素的事件处理函数也会触发，而且触发顺序可能是先捕获再冒泡。实测里我会用下面这段代码验证：
document.querySelector('.parent').addEventListener('click', () => { console.log('parent 冒泡阶段触发'); }); document.querySelector('.parent').addEventListener('click', () => { console.log('parent 捕获阶段触发'); }, true); document.querySelector('.child').addEventListener('click', () => { console.log('child 目标阶段触发'); });点击 .child 后，控制台输出顺序是：parent 捕获阶段触发 → child 目标阶段触发 → parent 冒泡阶段触发。这个输出顺序如果你不看控制台就能准确说出来，说明事件流模型你已经真正理解了。很多人排查事件问题无从下手，根源就在于不知道事件此刻处于哪个阶段、会按什么顺序经过哪些节点。
1.2 三种绑定方式，为什么最后只剩 addEventListener
JavaScript 里绑定事件有三种写法：HTML 内联、DOM0 级、DOM2 级。我面试前端时经常会问区别，很多人能说出 addEventListener 可以绑多个，但深层原因讲不清楚。
HTML 内联是写在标签上的 onclick：
<button onclick="handleClick()">点击</button>这种写法的致命问题在于：第一，逻辑混在 HTML 里，维护起来非常痛苦；第二，内联函数的作用域链会变得诡异，this 指向和全局变量访问都可能踩坑。DOM0 级是直接给元素的事件属性赋值：
btn.onclick = function() { console.log('第一次绑定'); }; btn.onclick = function() { console.log('第二次绑定'); };这么写只会输出“第二次绑定”，因为事件处理器属性是一个“坑位”，后赋值的会覆盖前面的。这在很多业务场景下不够用，比如第三方库和你的业务代码同时想监听同一个按钮点击。
真正推荐的是 DOM2 级的 addEventListener。它有三点核心优势：支持同元素同事件绑定多个监听器，彼此不会覆盖；可以通过第三个参数控制监听在捕获阶段还是冒泡阶段触发；可以用 removeEventListener 精确移除监听。选型上没有悬念，项目里统一用 addEventListener 就够了，内联写法只在极少数快速验证的场景才用得上。
1.3 事件处理函数与业务逻辑解耦：写着写着就顺手了
事件处理还有一个很多人忽略的设计问题：你的事件处理函数里是不是堆了太多东西？比如一个按钮点击事件里，先取表单值、再校验、再发请求、再更新页面、再埋点上报，全塞进一个匿名函数。
这种写法的维护成本会随着项目膨胀急剧上升。我的习惯是让事件处理函数只做两件事：拿到 event 对象，把数据提取出来，然后调用真正处理业务的纯函数。纯函数不依赖 DOM、不依赖 this，只接收参数返回结果，测试的时候不需要在浏览器里模拟点击，直接跑单测就够了。
// 业务逻辑拆成独立函数 function validateAndSubmit(formData) { const error = validate(formData); if (error) return { ok: false, error }; return submit(formData); } // 事件监听里只做获取数据和调用 submitBtn.addEventListener('click', (event) => { event.preventDefault(); const formData = collectFormData(); const result = validateAndSubmit(formData); renderResult(result); });这样设计之后，业务逻辑可以单独复用，事件回调变得非常薄，出问题定位也快。记住这个原则：事件处理程序是“连接用户操作和业务逻辑的胶水”，胶水不应该盖过业务本身。
2. 事件对象与监听器核心细节：别只盯着 e.preventDefault
2.1 event 对象里最容易被忽略的几个属性
事件处理函数拿到的第一个参数就是 event 对象，新人往往只知道 e.preventDefault 和 e.stopPropagation，用着用着发现不够用。我整理几个高频但容易被忽略的属性。
target 和 currentTarget 是排查问题时的关键区别。target 是事件真正触发的元素，currentTarget 是当前正在执行监听器的元素。比如 ul 上绑定了点击事件，你点中了一个 li 内部的 span，此时 target 是 span，currentTarget 是 ul。很多事件委托的 bug 就是混淆了这两个属性，导致拿不到预期的元素。
event.eventPhase 可以判断当前事件处于哪个阶段，0 表示没有正在处理、1 表示捕获阶段、2 表示目标阶段、3 表示冒泡阶段。调试事件顺序时我经常打这个属性看事件流走到哪了。
event.defaultPrevented 用来检测 preventDefault 是否被调用过。这个属性的实际价值在于：当你写了一个通用处理函数，想知道某个事件在链条上游是否已经被别人拦截过默认行为，直接看这个值就行，不用自己维护标记变量。
还有一个被低估的是 event.detail。在 click 事件里它表示点击次数（双击会变成 2），在 CustomEvent 里它携带自定义数据。做双击和单击区分时，用 detail 比自己在全局变量里维护时间戳要靠谱得多。
2.2 addEventListener 第三个参数：不是简单的 true/false
addEventListener 第三个参数，很多人只知道传 true 就是捕获阶段，不传就是冒泡阶段。但标准里它还接受一个对象：{ capture: true, once: true, passive: true }。
once 字段表示监听器只执行一次，执行完自动移除。支付按钮、提交按钮“防止重复点击”的场景，用 once 比在回调里手动 removeEventListener 省事得多。
passive 字段是我重点想说的。当你在 window 或 document 上监听 touchmove、wheel 这类高频滚动事件时，浏览器无法提前判断你调不调用 preventDefault，于是必须等你的监听器执行完才决定要不要滚动，这会带来明显卡顿。传 { passive: true } 就是告诉浏览器“我这个监听器不会阻止默认行为，你可以放心先滚”，性能提升明显。但注意，如果在 passive 为 true 的事件处理函数里调用 preventDefault，浏览器会报错且不生效。新版浏览器对 touchmove、wheel 的默认 passive 值已经做了调整，写代码时不要想当然。
// 滚动事件优化：明确告诉浏览器不会阻止默认行为 window.addEventListener('wheel', handleWheel, { passive: true }); // 只执行一次，适合“首次曝光”埋点 btn.addEventListener('click', reportOnce, { once: true });第三个参数用的场景虽然不如第一个参数多，但一旦遇到性能问题或者一次性事件，它是最优解。还有个现代技巧：使用 AbortController 的 signal 来统一移除监听，这在单页应用切换路由、清理组件副作用时非常方便：
const controller = new AbortController(); window.addEventListener('scroll', handler, { signal: controller.signal }); // 离开页面时统一移除 controller.abort();2.3 自定义事件：让模块之间的通信更优雅
事件处理不只能处理浏览器内置事件，你还可以自己派发事件。CustomEvent 是组件间解耦通信的一把好手，只是很多人写前端到现在都没用过。
先看一个场景：列表页点击某条数据后，需要让侧边栏刷新详情、让面包屑更新文字、让埋点模块记录行为。如果通过“调用对方模块的全局函数”来做，模块之间会形成强耦合，过两个月你再动其中一个，就可能不小心改坏另一个。用自定义事件，数据发布者只负责派发事件，消费方各自监听，彼此不认识：
// 某模块数据变化后，派发一个事件 function onDataChange(data) { const event = new CustomEvent('data:change', { detail: data, bubbles: true, }); document.dispatchEvent(event); } // 其他模块各自监听 document.addEventListener('data:change', (event) => { renderDetail(event.detail); }); document.addEventListener('data:change', (event) => { trackBehavior(event.detail); });这里我把事件名写成了 data:change，带冒号不是必须的，但规范化的命名能一眼看出业务含义。bubbles 字段也要注意，默认是 false，表示事件不会冒泡；如果你想让某个自定义事件像普通事件一样能够被上层容器捕获或委托，就把它设为 true。
自定义事件本质上就是观察者模式的一种实现。它能让代码从 A 调用 B 变成 A 发消息、B 回应，模块之间只通过约定的事件类型通信，而不是通过具体实例引用，这在项目大了之后尤其有价值。
3. 实操环节：高频场景的完整实现与复盘
3.1 动态列表事件委托：批量绑定与动态插入一起解决
先说一个很多人踩过的坑。页面上有一个 ul，你给它下面的 10 个 li 都绑了点击事件，一切正常。然后你通过 JavaScript 往 ul 里又 append 了一个新 li，结果发现这个新 li 怎么点都没反应。原因很简单：你在绑定事件的时刻，这个 li 还不存在。
解决这个问题有两个思路：一是每次新增节点后再给新节点单独绑定，但绑定逻辑散落各处，很容易重复绑定，越写越乱。二是用事件委托：把监听器绑在 ul 上，利用事件冒泡机制，事件触发后再用 target 判断“你到底点的谁”。事件委托才是正解。
const list = document.querySelector('#list'); list.addEventListener('click', (event) => { const li = event.target.closest('li'); if (!li) return; // 点到了 list 空白区域 console.log('触发的 li：', li.dataset.id); li.classList.add('active'); });这里有个细节必须提醒：点中 li 里的文字时 event.target 是文本节点所在的元素，可能是 li 内部的 span、a 或者 em，直接拿 target 跟 li 比较会失效。所以要用 closest('li') 从 target 往上找到最近的 li。如果找不到说明点击的就是 li 外的空白区域，直接 return，这也是事件委托最优雅的地方：一个监听器处理所有子元素，不管是初始节点还是后来动态插入的节点。
做事件委托时建议顺手封装一个工具函数，避免每个组件里重复写一堆判断：
function delegate(container, selector, type, handler) { container.addEventListener(type, (event) => { const target = event.target.closest(selector); if (target && container.contains(target)) { handler.call(target, event, target); } }); } delegate(list, 'li', 'click', (event, li) => { console.log('点击了：', li.dataset.id); });这里还要注意 container.contains(target) 的判断，防止 target 是容器外被 append 进来的元素时也触发 handler。
3.2 表单提交、输入校验与防抖：事件处理三件套
表单处理是事件处理的高频实战场景。最基本的是 submit 事件里 preventDefault，阻止页面刷新：
document.querySelector('#loginForm').addEventListener('submit', (event) => { event.preventDefault(); const formData = new FormData(event.currentTarget); // 走自己的异步请求 });新人最容易困惑的是：为什么用 click 事件监听提交按钮再手动提交，不如直接监听 form 的 submit？因为用户不只会点按钮，还可能在输入框里按回车，按回车触发的也是 form 的 submit 事件。监听 submit 可以把所有提交路径统一收口，还能用 HTML5 校验规则配合 submit 事件做二次校验。
接下来是输入场景。搜索框每敲一个字符都要发搜索请求，如果不做防抖，不到一秒钟可能打出几十次请求，后端大概率会报警。防抖的核心思想是“延迟执行，如果在等待时间内再次触发，就重新计时”：
function debounce(fn, delay = 300) { let timer = null; return function(...args) { window.clearTimeout(timer); timer = window.setTimeout(() => { fn.apply(this, args); }, delay); }; } searchInput.addEventListener('input', debounce(function(event) { console.log('发送搜索请求:', event.target.value); }, 500));实际开发中还有一个容易忽略的点：拿到键盘事件时，用 event.code 还是 event.key。判断快捷键时两个属性都比较常见，但含义不同。event.code 是物理按键的位置，比如 KeyA，按键盘 A 键无论中英文都是它；event.key 是输入的字符值，收到中文输入法状态下可能等于一个汉字。如果你做的是快捷键系统，用 code 更稳；如果你是想监听“用户输入了什么内容”，用 key。还有个经典坑：中文输入法选词时 keydown 会被触发，导致按下 Enter 选词也被当成表单提交，解决方式是监听 compositionend 事件来判断是否处于输入法组合状态。
3.3 媒体加载完成的判断：load 事件与 readyState 配合
热搜里我看到“检查静态资源是否加载完成”，这个用事件处理来解决非常典型。比如视频播放器，加载完成后才能显示时长、才能点击播放按钮。很多人在 video 标签上监听 load 事件，发现时灵时不灵，原因在于：资源可能已经从缓存加载完毕，load 事件已经到了，或者你监听的时候资源就已经加载完成，事件再也不会触发。
稳定的做法是加载完先判断 readyState：
const video = document.querySelector('#myVideo'); function initPlayer() { if (video.readyState >= 2) { setupPlayer(); } else { video.addEventListener('loadedmetadata', setupPlayer, { once: true }); } } function setupPlayer() { console.log('视频元数据加载完成，时长：', video.duration); } initPlayer();这里 readyState 的数字含义是：0 无数据，1 元数据已获取，2 当前帧可用，3 至少两帧可播放，4 流式播放可用。判断“能不能开始初始化播放器”，用 2 以上基本够。类似套路也适用于图片：img 的 complete 属性加 load 事件回调，是判断图片是否加载完的可靠组合。
3.4 媒体控制里的事件联动：小而完整的实战案例
继续以视频为例子，热搜里有人写了document.querySelector('video').style.rotate = '-90deg'这种旋转视频的用法，语法本身没毛病，但如果你要用事件处理做一个完整的播放控制面板，逻辑会和纯一行样式操作完全不同。我通常会在 loadedmetadata 事件里读取视频尺寸、初始化播放器的显示比例，在 play 和 pause 事件里切换播放/暂停按钮的状态，用 timeupdate 事件更新进度条，用 ended 事件触发“下一集”逻辑。
video.addEventListener('play', () => { playBtn.classList.add('is-playing'); }); video.addEventListener('pause', () => { playBtn.classList.remove('is-playing'); }); video.addEventListener('timeupdate', () => { const pct = (video.currentTime / video.duration) * 100; progressBar.style.width = `${pct}%`; });timeupdate 事件触发频率比较高，但它不是每帧触发，而是由浏览器根据播放速度决定。如果你需要精确的当前帧，只能用 requestAnimationFrame 配合 currentTime 自己驱动。所以做播放器项目时，优先级需求要提前想清楚：进度条精度要求高不高，决定你用 timeupdate 还是 rAF。
4. 常见问题与排查技巧实录：这些坑我实战里都踩过
4.1 内存泄漏：为什么页面越用越卡
页面用着用着越来越卡，甚至直接卡死，很多时候不是性能算法问题，而是事件监听器绑了不清理，导致内存里堆积了大量无用的闭包和对象。典型场景是单页应用里频繁切换页面，每次进入页面都往全局对象上挂监听器，离开时却不移除；还有给 window 和 document 绑定 resize、scroll 事件的，这类全局事件不会随 DOM 销毁而自动解除。
// 反面教材：每次打开弹窗都往 document 上挂 keydown function openModal(modal) { document.addEventListener('keydown', handleEsc); modal.classList.add('open'); } // 但是关闭时忘了 document.removeEventListener('keydown', handleEsc)排查内存泄漏的流程我也分享下：打开开发者工具 Performance，录制一段操作，观察监听器数量是否持续增长；或者在 Memory 面板抓一份堆快照，再操作、再抓快照，对比两次快照里 Detail 视图下有没有大量重复的 EventListener。修复思路其实很朴素：绑定在哪里，就在对称的生命周期里移除，比如 openModal 里加了监听，closeModal 里就必须 remove。用前面提过的 AbortController，把多个监听器挂到同一个 signal 上，一次 abort 全部移除，是更省心的方案。
结合我自己的经验，代码评审时重点盯两类：一类是给全局对象绑的事件有没有对应清理，另一类是使用了 bind 或箭头函数返回的函数有没有在移除监听时保持同一个引用。如果每次移除时都新写一个 function，removeEventListener 是匹配不上的，因为函数引用不同，等于没移除。
4.2 冒泡陷阱：点击弹窗内部，结果弹窗被关了
拦截冒泡是另一个高频 bug。我见过一个遮罩层点击关闭弹窗的实现，写在 mask 的 click 事件里，结果点击弹窗里任何一个按钮，弹窗瞬间就被关掉了。原因就是事件从弹窗内部一路冒泡到了 mask，触发了关闭逻辑。
经典的修复方式是在弹窗内部的点击事件里加 stopPropagation：
modal.addEventListener('click', (event) => { event.stopPropagation(); });不过如果弹窗内部还有多级嵌套，每个子区域都写 stopPropagation 会非常繁琐。更好的做法是在判断目标时精确控制：
mask.addEventListener('click', (event) => { if (event.target === mask) { closeModal(); } });这个写法利用的是 target 是真正触发的节点：点击只有点在遮罩本身时才关闭，点弹窗里任何内容都不会关闭，不需要逐级 stopPropagation，维护起来更省心。stopPropagation 不是敌人，但要克制使用，因为一旦某个事件在链路中被拦截，其他模块可能完全接收不到这个事件，排查时非常费劲。
4.3 一个极端但真实的监听器数量问题：scroll 事件别绑太重
scroll 和 resize 这类高频事件，一定要在外面包一层“节流/防抖”或者用 passive 做优化。我处理过一个数据列表无限加载的功能，最初直接在每个单元格更新时绑定 scroll 监听，导致滚动一帧要执行几十次回调，页面掉帧明显。
优化方案是事件 + 节流：
function throttle(fn, interval = 200) { let last = 0; return function(...args) { const now = Date.now(); if (now - last >= interval) { last = now; fn.apply(this, args); } }; } window.addEventListener('scroll', throttle(() => { applyVirtualListQuery(); }, 200), { passive: true });另外，很多新手会问“scroll 事件里拿到当前的 scrollTop 会不会触发重排”。会，因为你读取了 document.documentElement.scrollTop 或 getBoundingClientRect 这类布局信息，浏览器为了给你准确值，必须强制同步计算布局，这就是“强制同步布局”。高频滚动回调里要尽量避免读取布局属性，或者至少保证读取和写入的节奏合理。
4.4 不同浏览器之间的兼容性问题，现在还需要处理吗
早些年写事件处理，必须处理 addEventListener 和 attachEvent 的兼容，这是老项目能够跑起来的前提之一。现在的浏览器环境已经好很多，addEventListener 已经普遍支持，attachEvent 只在 IE8 及以下版本存在，这类代码几乎可以从新项目里消失了。不过有两件事还是值得注意。
一个是事件对象的兼容：老版本 IE 里事件对象不是事件处理函数的参数，而是挂在 window.event 上。现代代码不需要做兼容，但如果你维护的是老系统，遇到 undefined 问题可以先检查一下是不是这里出了问题。另一个是自定义事件的前缀：旧版浏览器使用 document.createEvent('CustomEvent') 配合 initCustomEvent，和现在的 new CustomEvent 写法不同，同样只需在老项目里关注。
5. 事件处理能力的扩展视野：从原生到框架、从页面到业务
5.1 框架里的合成事件：为什么 React 里事件处理不太一样
如果你之后接触 React，会发现它的 onCick、onChange 看起来很像原生事件，但实际是 React 自己实现的合成事件。React 17 之后，合成事件不再冒泡到 document，而是挂载在根容器上，所有的 click 处理函数会通过事件委托统一回收并分发。
为什么要理解这个差异？因为有些在原生事件中成立的经验，在框架里会出问题。比如你在 React 的 onClick 里调用 stopPropagation，只能阻止合成事件继续传播，却不能阻止原生事件继续往 document 上传。如果你在 document 上手动绑定了一个原生 click 监听，React 组件里的 stopPropagation 对它是无效的，两者混用时要注意区分。
另一个框架问题是 useEffect 的闭包捕获。在 React 里给 window 绑定原生事件时，很容易在事件回调里读到旧的 state，因为回调函数闭包捕获的是渲染当时的变量。解决这类问题需要配合 useRef 或者依赖更新时重新绑定，这已经是框架层面的事件处理知识了。但了解原生事件处理机制，是理解这些边界情况的前提。
5.2 事件驱动思维：不只是 DOM API，更是一种架构思想
事件处理的本质，其实是“当某种变化发生时，通知所有关心这个变化的人”。这个思维模型也能用在非 DOM 场景。比如 Node.js 里的 EventEmitter、浏览器端的 WebSocket 消息分发、前端状态管理库的发布订阅，本质上都脱离不开事件驱动。
我建议有精力的读者做一个小练习：用事件机制实现一个简单的事件总线，不依赖任何第三方库。
class EventBus { constructor() { this.events = new Map(); } on(type, handler) { if (!this.events.has(type)) { this.events.set(type, []); } this.events.get(type).push(handler); } emit(type, payload) { const handlers = this.events.get(type) || []; handlers.forEach((handler) => handler(payload)); } off(type, handler) { const handlers = this.events.get(type) || []; const index = handlers.indexOf(handler); if (index > -1) handlers.splice(index, 1); } } const bus = new EventBus(); bus.on('user:login', (user) => console.log('用户登录', user)); bus.emit('user:login', { name: '张三' });这个练习虽然简单，但“监听、派发、移除”三个核心操作，和 DOM 事件处理完全同构。做完之后你会理解，事件不只是一种 API，更是一种解耦的思考方式。后面学 Node.js、学 Vite 插件机制、学浏览器扩展开发，都会发现事件驱动思想无处不在。
我个人在实际开发里最大的体会是：事件处理写得乱不乱，和业务的清晰度直接挂钩。先把事件流模型刻在脑子里，遇到任何“点了没反应”“多点了几次”“又触发了一遍”的疑难杂症，先别急着搜代码，尝试在控制台里打印事件对象、看事件冒泡路径，往往比盲目改代码更有效。
最后再分享一个我几乎每个项目都会做的小动作：给所有 addEventListener 写满清楚的事件名和处理函数名，不要堆匿名函数。别小看这个习惯，项目上线两个月后，你回来调试一个线上的 bug，能一眼从代码堆里认出哪个函数是这个事件的处理逻辑，真的能省下大把时间。
