15.4 事件委托（事件代理）原理与性能优势

在 Web 开发中，经常需要给一组元素绑定相同的事件处理逻辑——例如一个列表中的每个列表项被点击时都要高亮显示。如果为每一个元素单独绑定事件处理器，不仅代码冗长，还会带来性能开销。事件委托正是为了解决这一问题而生的技巧，它利用事件冒泡机制，用一个父级元素上的监听器来管理所有子元素的事件。

15.4.1 事件委托的核心原理

事件委托依赖的是事件流中的冒泡阶段。当子元素上发生某个事件（如 click）时，事件会沿着 DOM 树一路向上冒泡，最终到达 document 甚至 window。在这个路径上的任何祖先元素都可以监听到该事件，并且可以通过 event.target 属性知道事件最初是在哪个元素上触发的。

因此，事件委托的步骤可以归纳为：

将事件监听器绑定到子元素的公共祖先上（比如 ul 列表绑定在 ul 上，或更上层绑定在 document 上）。
当事件触发时，通过 event.target 获取实际点击的元素。
判断 event.target 是否是我们关心的子元素（或符合某些选择器条件），如果是则执行相应处理逻辑。

// 不使用事件委托：为每个 li 绑定事件
const items = document.querySelectorAll('.list-item');
items.forEach(item => {
  item.addEventListener('click', () => {
    console.log('点击了：', item.textContent);
  });
});

// 使用事件委托：在父级 ul 上绑定一个事件
const list = document.getElementById('list');
list.addEventListener('click', (event) => {
  // 判断实际点击的元素是否是 li
  if (event.target.tagName === 'LI') {
    console.log('点击了：', event.target.textContent);
  }
});

如果需要更灵活的选择器匹配，可以使用 event.target.matches() 方法，或者通过循环向上查找 event.target 的祖先元素来判断是否匹配目标选择器（处理元素内部嵌套时尤其有用）。

// 处理更复杂的嵌套结构：可能点击的是 li 内部的 span 等
list.addEventListener('click', (event) => {
  const target = event.target.closest('.list-item');
  if (target && list.contains(target)) {
    console.log('点击了：', target.textContent);
  }
});

15.4.2 事件委托的性能优势

将事件绑定从“每个元素”提升到“一个公共祖先”，带来的性能收益主要体现在以下三个方面：

1. 减少内存占用

每个事件监听器都是一个对象，会占用内存。如果有成百上千个元素需要绑定事件，这些监听器的累积内存开销会非常可观。事件委托只创建一个监听器，无论子元素数量如何增加，内存占用几乎不变。在移动端或资源受限环境下，这种优化尤为关键。

2. 减少 DOM 操作与初始化时间

addEventListener 本质上也是 DOM 操作。大量元素的逐个绑定会延长页面初次渲染的时间。事件委托将所有绑定合并为一次 DOM 操作，初始化更快，也让页面响应更敏捷。

3. 简化动态元素的处理

对动态添加或移除的子元素，传统方式需要在每次增删时重新绑定或解绑事件；而事件委托自动覆盖所有现存及未来添加的子元素，因为监听器在父级上，不关心子元素何时创建。这大大降低了管理复杂性，也避免了因忘记解绑导致的内存泄漏。

// 动态添加一个 li 后，无需额外绑定事件
const newItem = document.createElement('li');
newItem.className = 'list-item';
newItem.textContent = '新项目';
list.appendChild(newItem);
// 点击新添加的 li，同样会触发父级的委托监听器

15.4.3 事件委托的适用场景与注意事项

适用场景

列表、表格、菜单等大量同类型元素需要相同交互行为。
需要处理动态增删内容的区域（如无限滚动加载的列表、聊天消息区）。
减少全局事件注册，统一管理同类型事件逻辑。

不适用场景

需要禁止冒泡的事件（比如 focus、blur 默认不冒泡，虽然可以改用 focusin 和 focusout）。
需要严格控制事件处理顺序且不希望冒泡带来的干扰时。
对性能极其敏感的个别高频事件（如 scroll、mousemove），仍需结合节流等手段，委托本身也可能需要额外判断目标元素，消耗少量 CPU，不过通常可以忽略不计。

注意点

委托绑定层级不宜过高，如果event.target与预期目标之间包含大量无关元素，可能会做很多无效判断。父级最好选在直接容器，而不是 document（除非需要全局代理）。
需要小心处理 event.stopPropagation() 的影响。如果某个子元素上绑定了停止冒泡的事件处理器，会导致委托在父级的事件无法触发，因此使用委托时一般应避免在子元素上阻止冒泡。
event.target 可能不是期望的元素本身，而是其内部子节点（比如 li 内的 span）。推荐使用 closest() 方法进行向上查找匹配。

15.4.4 一个更真实的例子：表格行点击高亮

假设有一个可排序的表格，每行点击后高亮，并且数据可以动态增加：

const table = document.getElementById('data-table');
table.addEventListener('click', (event) => {
  const row = event.target.closest('tr');
  if (!row || !table.contains(row)) return;
  
  // 移除其他行的高亮样式
  table.querySelectorAll('tr.highlight').forEach(tr => tr.classList.remove('highlight'));
  // 为当前行添加高亮
  row.classList.add('highlight');
});

无论表格中现有 10 行还是 1000 行，甚至后续通过 AJAX 再插入新行，这段代码都始终有效，且只占用一个事件监听器的资源。

事件委托本质上是对 DOM 事件流模型的巧妙运用，它将“每个元素各自为战”变为“集中管理”，既提升了性能，又简化了动态内容的交互逻辑。在前端优化中，这个技巧成本低、收益高，值得作为默认实践之一。