事件委托依靠事件冒泡机制，将监听绑定在父元素上，通过event.target和closest()精准识别目标元素，支持动态元素且避免重复绑定，但需合理选择委托层级并注意非冒泡事件限制。

事件委托靠的是事件冒泡机制

JavaScript事件委托不是新注册一个事件类型，而是把事件监听绑定在父元素上，利用 click、input 等原生事件的冒泡特性，在父级捕获子元素触发的事件。前提是目标元素必须是可冒泡的（比如 div、button），而像 focus、blur 这类不冒泡的事件不能直接委托。

用 event.target 区分真实点击对象

绑定在父元素上的回调函数里，不能直接用 this 或 event.currentTarget 当作被点中的元素——它们指向父容器。真正被用户交互的元素是 event.target，但要注意它可能是子元素的子元素（比如按钮里的 span）。所以通常要向上查找匹配的“业务目标”：

document.getElementById('list').addEventListener('click', function (e) {
  const item = e.target.closest('li');
  if (item) {
    console.log('点了第', item.dataset.index, '项');
  }
});

• e.target.closest('li') 比反复判断 nodeName 或遍历 parentNode 更安全可靠
• 如果用 querySelector 类方法做匹配，注意避免误选到非直系子元素（比如嵌套的 li）
• 旧版 IE 不支持 closest()，需用 polyfill 或降级为 matches() + 循环

动态添加元素时不用重复绑定

这是事件委托最实在的性能收益点：当列表频繁增删 li 时，传统做法是每次新增都调用 element.addEventListener('click', handler)，既浪费内存又容易漏绑或重复绑定。委托后只需一次监听，后续所有 li 都自动生效。

• 尤其适合虚拟滚动、无限加载、实时聊天消息等场景
• 不需要维护事件监听器引用，也规避了 removeEventListener 忘记解绑导致的内存泄漏
• 但要注意：如果父容器本身也频繁销毁重建（比如整个 #list 被 innerHTML = ''），委托就失效了，得重新绑定

委托层级过深会轻微影响性能

理论上事件从目标元素逐层向上冒泡，每经过一层都要执行事件监听器判断逻辑。虽然现代浏览器优化得很好，但若把监听器挂在 document 上处理所有按钮点击，就可能因条件判断过多拖慢响应。

• 优先委托到最近公共父级，比如表格操作委托到 tbody，而不是整个 body
• 避免在委托回调里做重计算（如频繁 DOM 查询、正则匹配），可提前缓存选择器或用 data-action 属性分流
• 移动端要注意 touchstart 冒泡行为和 click 有延迟差异，委托时建议统一用 click 或明确处理 touch 事件