事件委托是日常开发必需掌握的底层机制，依赖冒泡路径，需区分event.target与currenttarget；click等可委托，mouseover易误判，mouseenter/leave不冒泡；addeventlistener第三参数决定捕获或冒泡阶段；应优先用matches()和dataset精准过滤目标，避免parentnode遍历和滥用stoppropagation。
事件委托不是“高级技巧”，而是日常开发里必须会用、也经常写错的底层机制。它能解决动态元素绑定失效、内存暴涨、重复监听等问题，但前提是理解清楚冒泡路径和 event.target 与 event.currentTarget 的区别。
为什么 click 可以委托，mouseover 却容易出错
因为事件委托依赖事件冒泡，而并非所有事件都稳定冒泡：
-
click、keydown、submit等事件冒泡路径清晰，event.target总能准确指向被点击的真实元素 -
mouseover在子元素间移动时会频繁触发（比如从父<div> 移入其内部 <code><span></span>，会先触发父的mouseout再触发子的mouseover），导致误判 -
mouseenter/mouseleave根本不冒泡，委托完全无效——这点常被面试者忽略 - 真实项目中若真要处理悬停逻辑，应优先考虑 CSS
:hover，或用mouseover+event.relatedTarget做边界判断，而不是硬套委托 - 默认为
false（即冒泡阶段），这是事件委托的常规用法，父元素能捕获子元素冒上来的click - 设为
true（捕获阶段），事件会从document→body→ 父容器 → 子元素逐层向下，此时event.target还是真实目标，但event.currentTarget是当前捕获途中的节点——容易混淆，且对委托无实际增益 - 现代写法推荐显式传
{ once: false, capture: false }，避免靠布尔值记忆语义 - 切记：委托代码里不要在父元素上同时用捕获+冒泡监听同一事件，否则可能触发两次
- 优先用
Element.matches(selector)判断，支持类名、属性、伪类等，比className.includes或tagName === 'BUTTON'更可靠 - 对有层级结构的按钮（如
<button data-action="save"></button>），直接读target.dataset.action比检查 class 更轻量 - 避免用
parentNode向上找容器再判断——如果 DOM 结构微调（比如加了一层<div>），逻辑就断了；应始终基于 <code>event.target本身做匹配 - 注意
target可能是文本节点或 SVG 子元素，加个target.nodeType === Node.ELEMENT_NODE安全校验
addEventListener 第三个参数 false/true 的影响
这个布尔值决定监听器注册在冒泡阶段还是捕获阶段，直接关系到事件委托能否生效：
如何安全地过滤目标元素（避免 if-else 堆砌）
委托的核心是“统一监听 + 精准分流”，但硬写一长串 if (target.matches('.btn-delete')) {...} 很难维护：
真正容易被忽略的点是：委托不是万能胶。当父容器本身需要响应同类型事件（比如整个卡片可点击，但内部按钮又要单独处理），就必须用 event.stopPropagation() 截断冒泡——但这会破坏委托链，得提前设计好事件流层级，而不是事后补 stopPropagation。
