事件委托是利用事件冒泡机制，将子元素事件绑定到共同父元素上，通过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);
}
});
什么场景下别硬套事件委托？
它不是银弹：
立即学习“Java免费学习笔记（深入）”；
- 子元素极少（比如就 3 个导航项），直接绑定更清晰，委托反而绕弯
- 需要精确控制捕获阶段（比如拦截滚动前动作），委托依赖冒泡，捕获阶段拿不到子元素事件
- 子元素本身有复杂交互（如拖拽 + 点击共存），
event.target可能是内部 span 或 icon，需额外向上遍历closest()，增加判断成本
真正该用的时候，是当你看到控制台里一堆重复的 addEventListener 调用，或每次 innerHTML += ... 后都要补绑事件——那说明你已经站在坑边了。
