事件委托本质是利用事件冒泡与target判断，将监听器绑定父元素，通过event.target.matches()精准匹配目标元素；适用于动态结构，但遇stoppropagation、pointer-events:none或高频事件时失效。
事件委托的本质是利用事件冒泡 + target 判断
事件委托不是“把事件交给别人处理”，而是把事件监听器统一绑定在父元素上，等子元素触发事件后，靠 event.target 找到真正被点击的元素。核心前提是：大多数交互元素（如列表项、按钮组）有共同父容器，且结构动态变化频繁（比如通过 innerHTML 或 appendChild 增删节点）。
如果不委托，每新增一个按钮就得调一次 element.addEventListener；委托后，哪怕后续插入 100 个新 li，也不用重新绑定。
用 addEventListener 绑在父级，再用 event.target.matches() 精准匹配
别用已废弃的 event.srcElement 或手动遍历 parentNode，现代写法应依赖 matches() 做语义化判断。它支持选择器字符串，可读性高、兼容性好（IE9+）。
- 避免用
if (e.target.className === 'btn')—— class 可能是多个，或带空格/前缀 - 不要写
e.target.tagName === 'BUTTON'—— 太宽泛，无法区分功能按钮和装饰按钮 - 推荐写法：
e.target.matches('.action-btn[data-action="delete"]')
const list = document.getElementById('item-list');
list.addEventListener('click', function(e) {
if (e.target.matches('button.delete-btn')) {
const id = e.target.dataset.id;
deleteItem(id);
}
});
委托失效的三个典型场景
不是所有情况都适合委托。以下情形会导致行为异常或性能倒退：
立即学习“Java免费学习笔记（深入）”；
-
event.stopPropagation()在子元素中被调用 —— 冒泡被截断，父级监听器收不到事件 - 父容器高度为
0或设置了pointer-events: none—— 事件根本不会触发 - 高频事件如
mousemove或wheel—— 每次移动都执行matches()判断，开销可能超过直接绑定
对 input 类型事件（如 input、change），委托虽可行，但要注意：它们不冒泡（input 本身会冒泡，但部分浏览器对 change 支持不一），建议优先用原生事件或框架封装逻辑。
委托不是银弹，要权衡事件流深度与判断成本
如果 DOM 层级极深（比如 15 层嵌套），事件从目标冒泡到委托容器耗时略增；而每次点击又要做多次 matches() 调用，反而不如直接绑定轻量。实践中更关键的是维护成本：动态内容越多，委托收益越明显；静态页面或单次渲染结构，直接绑定更清晰。
真正容易被忽略的是事件对象复用问题：某些环境下（如 React 合成事件），e.target 在异步回调中可能已失效，需提前缓存 const target = e.target 再操作。
