事件委托是利用事件冒泡机制，在父元素上统一监听子元素事件，通过event.target识别实际触发源，实现以一当百的高效事件管理。
事件委托就是让父容器“代收”子元素的事件，靠的是浏览器自带的冒泡机制——子元素一触发事件，就会自动往上传到父元素，你只需在父容器监听一次，再判断是谁点的，就能统一处理。
冒泡是基础，必须理解传播路径
点击一个按钮时，事件会按顺序经历三个阶段：捕获（从 window 往下）、目标（落在按钮上）、冒泡（从按钮往上传）。事件委托只依赖冒泡阶段。只要父容器在冒泡阶段监听，就能收到所有子元素发上来的同类型事件。
- event.target 是真正被点击的最内层元素（比如某个 li 或 button）
- event.currentTarget 是当前绑定监听器的元素（比如 ul 或 div 容器）
- 冒泡不会跳过中间层级，哪怕中间元素没监听该事件，它依然会继续上传
怎么写一个可靠的委托监听器
关键不在“绑在哪”，而在“怎么识别目标”。不能只靠 tagName，得考虑嵌套结构和动态内容。
- 用 e.target.matches('li') 判断是否点中了目标子元素（简洁安全）
- 遇到子元素内部还有文字、图标等嵌套，改用 e.target.closest('li') 向上找最近匹配项
- 避免直接操作 e.target 的父级或兄弟节点，防止因 DOM 变化导致逻辑错乱
- 监听器函数里加 guard clause，比如 if (!e.target) return，防边缘情况
为什么比逐个绑定更高效
不是“看起来省事”，而是有实质性能差异：
- 100 个按钮，传统方式要创建 100 个函数实例 + 100 次 addEventListener 调用；委托方式只要 1 个函数 + 1 次绑定
- 后续动态插入新按钮，无需重新绑定——它天然“继承”父容器的监听能力
- 内存占用更低，尤其在 SPA 或长列表场景中，减少 GC 压力
- 逻辑集中，修改响应行为只需动一处，不用遍历所有子元素更新
哪些情况不适合用委托
冒泡不是万能的，有些事件天生不冒泡，或者业务逻辑要求强隔离：
- focus、blur、mouseenter、mouseleave 等事件默认不冒泡，需用 focusin/focusout 或其他变通方式
- 子元素行为差异极大（比如有的要弹窗、有的要删除、有的要编辑），且无法通过 class 或 data 属性归类，委托后判断逻辑会臃肿
- 需要精确控制事件流（比如某一层必须拦截并 stopPropagation），委托会让控制粒度变粗
- 极简静态页面，只有三五个固定元素，委托反而增加理解成本
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
