事件委托依赖事件冒泡机制，通过在父元素监听并用event.target.matches()判断目标元素来实现高效、动态的事件处理。
事件委托依赖事件冒泡机制
事件委托能工作，根本原因是 DOM 事件会从目标元素向上逐级冒泡到 document。你不需要在每个子元素上绑定事件，只需在它们的共同父容器（比如 ul、div）上监听，再用 event.target 判断真正被点击的是哪个子节点。
常见错误是误以为委托能捕获所有事件——它只对支持冒泡的事件有效（click、mousedown、keyup 可以；focus、blur、mouseenter 不行，得用捕获或专门处理）。
如何正确绑定委托事件
核心是使用 addEventListener 在父元素监听，并在回调中检查 event.target 是否匹配预期选择器。现代写法推荐用 Element.matches() 做判断，兼容性好且语义清晰。
- 避免直接操作
event.target.className或nodeName——容易漏掉动态类名或大小写问题 - 如果委托目标是动态添加的元素，确保绑定位置足够高（比如挂到
document或稳定存在的父容器），否则新元素收不到事件 - 注意
this指向的是绑定事件的父元素，不是被点击的子元素；要用event.target获取实际目标
document.getElementById('list').addEventListener('click', function (e) {
if (e.target.matches('li button.delete')) {
e.target.closest('li').remove();
}
});
性能提升来自减少监听器数量和内存占用
每调用一次 addEventListener，浏览器就要创建并维护一个监听器对象。100 个按钮各自绑定 click，就是 100 个独立监听器；用委托，只需要 1 个。
立即学习“Java免费学习笔记（深入）”；
这不只是“少写几行代码”的问题：监听器越多，事件分发路径越长，GC 压力越大，尤其在频繁增删 DOM 的场景（如列表滚动、实时消息流）下差异明显。
- 委托不降低单次事件处理开销，但显著减少初始化和销毁成本
- 如果父容器层级太深（比如绑在
document上），可能增加不必要的冒泡路径，轻微拖慢响应——优先选最近的稳定祖先 - 不要在委托回调里做重操作（如遍历大量节点、触发 reflow），否则会放大单次延迟
委托失效的几个典型场景
看似用了委托，但点击没反应？大概率掉进了这几个坑：
-
event.stopPropagation()在子元素处理逻辑里被调用，阻断了冒泡路径 - 目标元素是
disabled的表单控件（如button[disabled]），它不会触发任何事件 - 监听器绑定时父容器还不存在（比如在 DOM 加载前执行 JS），或绑定后父容器被替换（如
innerHTML = ...）导致监听器丢失 - 用
onxxx属性（如onclick）绑定，它不支持委托逻辑，只能作用于当前元素
委托不是银弹——它解决的是“批量绑定 + 动态更新”场景下的监听器管理问题。如果只有两三个静态按钮，硬套委托反而让逻辑更绕。
