事件委托是利用事件冒泡机制，在父元素上统一监听子元素事件，通过event.target识别实际触发源，实现以一当百的高效事件管理。

事件委托就是让父容器“代收”子元素的事件，靠的是浏览器自带的冒泡机制——子元素一触发事件，就会自动往上传到父元素，你只需在父容器监听一次，再判断是谁点的，就能统一处理。

冒泡是基础，必须理解传播路径

点击一个按钮时，事件会按顺序经历三个阶段：捕获（从 window 往下）、目标（落在按钮上）、冒泡（从按钮往上传）。事件委托只依赖冒泡阶段。只要父容器在冒泡阶段监听，就能收到所有子元素发上来的同类型事件。

• event.target 是真正被点击的最内层元素（比如某个 li 或 button）
• event.currentTarget 是当前绑定监听器的元素（比如 ul 或 div 容器）
• 冒泡不会跳过中间层级，哪怕中间元素没监听该事件，它依然会继续上传

怎么写一个可靠的委托监听器

关键不在“绑在哪”，而在“怎么识别目标”。不能只靠 tagName，得考虑嵌套结构和动态内容。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 用 e.target.matches('li') 判断是否点中了目标子元素（简洁安全）
• 遇到子元素内部还有文字、图标等嵌套，改用 e.target.closest('li') 向上找最近匹配项
• 避免直接操作 e.target 的父级或兄弟节点，防止因 DOM 变化导致逻辑错乱
• 监听器函数里加 guard clause，比如 if (!e.target) return，防边缘情况

为什么比逐个绑定更高效

不是“看起来省事”，而是有实质性能差异：

立即学习“Java免费学习笔记（深入）”；

• 100 个按钮，传统方式要创建 100 个函数实例 + 100 次 addEventListener 调用；委托方式只要 1 个函数 + 1 次绑定
• 后续动态插入新按钮，无需重新绑定——它天然“继承”父容器的监听能力
• 内存占用更低，尤其在 SPA 或长列表场景中，减少 GC 压力
• 逻辑集中，修改响应行为只需动一处，不用遍历所有子元素更新

哪些情况不适合用委托

冒泡不是万能的，有些事件天生不冒泡，或者业务逻辑要求强隔离：

• focus、blur、mouseenter、mouseleave 等事件默认不冒泡，需用 focusin/focusout 或其他变通方式
• 子元素行为差异极大（比如有的要弹窗、有的要删除、有的要编辑），且无法通过 class 或 data 属性归类，委托后判断逻辑会臃肿
• 需要精确控制事件流（比如某一层必须拦截并 stopPropagation），委托会让控制粒度变粗
• 极简静态页面，只有三五个固定元素，委托反而增加理解成本