事件委托通过绑定父元素监听器并利用事件冒泡，由event.target识别真实触发目标，适用于动态内容和大量子元素场景，节省内存且自动支持新增元素，但不适用于不冒泡事件。
事件委托利用事件冒泡机制，把事件监听器绑定在父元素上，由父元素统一处理子元素的事件，而不是给每个子元素单独绑定。核心在于通过 event.target 判断真正触发事件的子元素。
事件委托如何工作
当用户点击某个子元素（如列表项 <li>），事件会从该元素向上逐层冒泡到父容器（如 <ul>）。如果父容器绑定了监听器，就能捕获这个冒泡上来的事件，并用 event.target 获取原始点击目标：
- 父元素必须是子元素的共同祖先，且能稳定存在（不能频繁被销毁重建）
- 监听器中通过
event.target.matches(selector)或属性判断来识别目标元素 - 例如：点击动态添加的按钮，只要它符合
button.delete选择器，就能被父级统一响应
相比直接绑定的优势
适合动态内容和大量子元素的场景：
- 节省内存：1 个监听器代替 N 个，避免重复绑定开销
- 自动支持动态元素：后续用 JS 插入的新子元素无需重新绑定事件
- 简化初始化逻辑：不用遍历 NodeList，也不用担心插入顺序或时机问题
相比直接绑定的劣势
不是万能方案，有其适用边界：
立即学习“Java免费学习笔记（深入）”；
-
事件必须支持冒泡：像
focus、blur、mouseenter等不冒泡的事件无法委托（可用focusin/focusout替代） -
增加判断开销：每次触发都要检查
event.target，对高频事件（如mousemove）需谨慎使用 - 调试稍复杂：事件实际绑定在父级，调用栈和事件源可能不如直觉清晰
什么时候该选哪种方式
没有绝对优劣，关键看场景：
- 静态、数量少、生命周期固定的元素 → 直接绑定更直观、性能略优
- 列表、表格、菜单等含动态增删项的结构 → 优先用事件委托
- 需要精确控制事件流（比如阻止冒泡影响其他逻辑）→ 直接绑定更容易掌控
- 全局快捷键或模态框遮罩层交互 → 常结合委托与捕获阶段（
useCapture = true）
不复杂但容易忽略：委托是否生效，取决于事件是否真的冒泡到了你绑定的那层，以及 event.target 是否是你想匹配的那个元素。
