事件委托是利用事件冒泡机制，将子元素事件绑定到共同父元素上，通过event.target判断实际目标。适用于内存受限、动态DOM、维护复杂场景；需精准匹配目标、避免stopPropagation阻断、锚定最近公共父容器；子元素极少或需捕获阶段时不宜使用。

事件委托就是把子元素的事件“甩锅”给父元素

它不是给每个 li、button 或 tr 单独绑 addEventListener，而是只在它们共同的父容器（比如 ul、div、table）上监听一次事件，再通过 event.target 判断实际被点击的是哪个子元素。本质是利用了事件冒泡机制——子元素触发的事件会一路往上传到父元素。

为什么用事件委托？三个硬需求真管用

它解决的不是“能不能”，而是“不得不”：

• 内存爆炸时必须用：1000 个列表项，传统方式要创建 1000 个函数实例；事件委托只创建 1 个，内存占用直降 99.9%
• 动态增删 DOM 时没法不用：AJAX 加载新列表项、React/Vue 局部更新、用户拖拽插入行……新增的元素天然继承父级绑定，完全不用调 addEvent 或 removeEvent
• 维护成本高到离谱时只能靠它：比如表格里每行都有「编辑」「删除」按钮，逻辑全挤在同一个父容器的回调里，改一处就全局生效，不会漏掉某个新插入的按钮

怎么写才不踩坑？关键三步不能少

常见错误是只监听、不判断，结果点哪都触发，或者误判目标元素：

• 必须检查 event.target 是否匹配你关心的子元素（比如 event.target.matches('button.delete')），不能直接用 event.target 做业务逻辑
• 注意事件冒泡中途被 event.stopPropagation() 阻断——如果某个子元素自己调了这句，父级委托就收不到事件了
• 别在 body 或 document 上无差别委托所有 click，性能差且容易误伤，精准锚定最近公共父容器（如 #user-list）

const list = document.getElementById('user-list');
list.addEventListener('click', function (e) {
  if (e.target.matches('button.edit')) {
    const userId = e.target.dataset.id;
    editUser(userId);
  } else if (e.target.matches('button.delete')) {
    const userId = e.target.dataset.id;
    deleteUser(userId);
  }
});

什么场景下别硬套事件委托？

它不是银弹：

• 子元素极少（比如就 3 个导航项），直接绑定更清晰，委托反而绕弯
• 需要精确控制捕获阶段（比如拦截滚动前动作），委托依赖冒泡，捕获阶段拿不到子元素事件
• 子元素本身有复杂交互（如拖拽 + 点击共存），event.target 可能是内部 span 或 icon，需额外向上遍历 closest()，增加判断成本

真正该用的时候，是当你看到控制台里一堆重复的 addEventListener 调用，或每次 innerHTML += ... 后都要补绑事件——那说明你已经站在坑边了。