事件委托是利用事件冒泡机制，将子元素事件绑定到共同父元素上，通过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);
}
});
什么场景下别硬套事件委托？
它不是银弹：
行盟APP1.0 php版
下载
行盟APP是结合了通信和互联网的优势，加之云计算所拥有的强大信息资源，借助广大的终端传递服务，潜在的拥有巨大商机。她到底是什么，又有什么作用？她是一款手机应用软件；她是一款专门为企业服务的手机应用软件；她是一款能够将企业各种信息放入其中并进行推广传播的手机应用软件！只要轻轻一点，企业的简介，产品信息以及其他优势就能最快最大限度的透过手机展现在客户的眼前，一部手机，一个APP，你面对的将是一个6亿&
立即学习“Java免费学习笔记（深入）”；
- 子元素极少（比如就 3 个导航项），直接绑定更清晰，委托反而绕弯
- 需要精确控制捕获阶段（比如拦截滚动前动作），委托依赖冒泡，捕获阶段拿不到子元素事件
- 子元素本身有复杂交互（如拖拽 + 点击共存），
event.target可能是内部 span 或 icon，需额外向上遍历closest()，增加判断成本
真正该用的时候，是当你看到控制台里一堆重复的 addEventListener 调用，或每次 innerHTML += ... 后都要补绑事件——那说明你已经站在坑边了。
