js 事件委托怎么实现有什么好处

事件委托的核心做法是：把原本要绑在多个子元素上的事件监听，改绑到它们共同的父元素上，借助事件冒泡和 event.target 判断真正被点击的是谁。好处也很直接：监听器从 N 个降到 1 个，动态新增的元素不用重新绑定，解绑也只需要一次。结论：事件委托 = 冒泡机制 + 目标元素判断，是一次“以空间换管理成本”的写法优化。

事件委托是什么，一句话怎么解释

事件委托（event delegation）指利用事件冒泡，把子元素的事件处理统一交给父元素监听。当点击子元素时，事件会从目标元素开始逐层向上冒泡到 document，父元素上的监听器因此也能收到这次点击，再通过 event.target 定位真正被点的子元素。

这里有两个前置概念：事件冒泡指事件从最深的触发节点向外层祖先节点依次传递；event.target 指实际触发事件的那个最深层元素，而 event.currentTarget 是当前正在执行监听器的元素，也就是绑定的父元素。区分这两个属性是写好委托的前提。

事件委托怎么实现（附可直接运行的代码）

实现只需三步：选父容器、绑一个监听器、在回调里判断事件源。

const list = document.querySelector('#list');

list.addEventListener('click', function (e) {
  // 从真实点击节点向上找最近的 .item
  const item = e.target.closest('.item');
  // 排除点击到容器本身或容器外部的情况
  if (!item || !list.contains(item)) return;

  console.log('点击了 id =', item.dataset.id);
});

关键点有三个：一是回调必须用普通函数（或显式取 e.currentTarget），箭头函数里的 this 指向外层作用域，拿不到父容器；二是 closest(selector) 会从当前节点一直向上找匹配的祖先，天然兼容“图标、文字包在子 span 里”的情况；三是 list.contains(item) 用来防止把容器自身或其外部元素误判成目标。

如果列表是动态渲染的（比如每次请求后 innerHTML 重写），这段代码一行都不用改，因为监听器挂在父容器上，子元素换几批都能生效。

为什么要用 closest 而不是直接判断 e.target

直接写 e.target.classList.contains('item') 是最常见的错误写法。用户点的往往是按钮里的 <span>、<i> 图标或文本节点，此时 e.target 是那个深层子元素而不是 .item 本身，判断会全部失效。

closest 解决的就是这层“目标不一定是你要的元素”的问题。注意 Element.closest() 在 IE 全系不支持，如需兼容 IE11，可以手写一个向上遍历的循环：

function closest(el, selector) {
  while (el && el.nodeType === 1) {
    if (el.matches(selector)) return el;
    el = el.parentElement;
  }
  return null;
}

事件委托有哪些好处

**结论：事件委托的最大收益是监听器数量从 O(n) 降到 O(1)，其次是天然支持动态元素。** 具体有三点：

第一，内存占用和绑定耗时下降。一个 1000 行的表格给每行绑 click，就是 1000 个监听器实例；用委托只需要 1 个。在低端移动设备上，这个差距在列表渲染时能明显感觉到。

第二，动态元素无需重新绑定。新增、删除、重新渲染子节点后，委托的监听器始终有效，不用在每次渲染后写一遍 bindEvent()，也不用担心旧节点没解绑造成的内存泄漏。

第三，解绑成本低。移除父元素时，挂在它上面的那一个监听器会随节点一起被回收，不需要遍历清理。

事件委托有什么局限，哪些事件不能委托

结论：不冒泡的事件不能用事件委托。 典型的是 focus、blur、mouseenter、mouseleave、load、unload、scroll（在部分场景下不冒泡）、mouseover/mouseout 虽冒泡但会因频繁触发带来问题。

focus 和 blur 有对应的冒泡版本 focusin 和 focusout，可以直接替换：

form.addEventListener('focusin', (e) => {
  if (e.target.matches('input')) e.target.classList.add('is-active');
});

另一个限制是中间层调用了 stopPropagation()，事件被截断，委托到祖先的监听器就收不到了。在混用第三方组件时要特别注意这一点。

还有性能反例：如果父容器下有几万个节点、点击频率极高，每次点击都要做一次 closest 的 DOM 查找，成本反而可能超过直接绑定。实践中单层列表、几百到几千节点规模，委托几乎总是更优。

最后提醒一个易忽略点：addEventListener 的第三个参数支持 { capture, once, passive }，委托时如果结合 passive: true（用于滚动性能优化），注意不要在同一次监听里调用 preventDefault()，否则不生效并会在控制台报警告。

综上，事件委托的落地路径很固定：父容器绑一次监听、closest 定位目标、contains 兜底校验、避开不冒泡事件。掌握这四点，列表点击、表格行操作、动态表单这类高频场景都能用一套代码稳定覆盖。