事件委托利用事件冒泡机制，让父元素统一处理子元素事件，通过e.target.closest()精准捕获目标元素，适用于动态列表、高频增删等场景，但不适用于focus等不冒泡事件。
事件委托的核心就是让父元素“代劳”子元素的事件处理，靠的是浏览器原生的事件冒泡机制。你不用给每个子元素单独绑监听器，只在父元素上设一个，再通过 event.target 准确识别点击的是谁——既省资源，又天然支持动态新增的元素。
为什么父元素能管住所有子元素？
因为点击某个子元素（比如按钮）后，事件会自动从它出发，一层层往上传到父元素、再往上到 body、最后到 document。这个“向上冒泡”的过程是浏览器默认行为，无需额外开启。你在父元素监听 click，只要事件冒泡没被 e.stopPropagation() 截断，就一定能捕获到。
- 子元素触发事件 → 事件开始冒泡
- 父元素上的监听器被激活 → 进入回调函数
- 用
e.target拿到真正被点中的 DOM 节点 - 用
e.target.matches('button.delete')或e.target.closest('button')做精准判断
怎么写才不容易出错？
常见问题不是原理不懂，而是细节踩坑：点到按钮里的文字、标签嵌套深、匹配逻辑松散。关键在“过滤要严，查找要稳”。
- 别直接比
e.target.tagName === 'BUTTON'——如果用户点的是按钮里的一段文字，e.target就是那个textNode，不是 button - 优先用
e.target.matches('button.delete')，它只认当前节点是否匹配选择器 - 更推荐
e.target.closest('button')，它会顺着父链往上找，哪怕点的是按钮内的图标或 span，也能正确捕获按钮本身 - 确保父容器是稳定存在的；如果是模态框这类每次新建的 DOM，监听器得挂到 document 上，或等插入文档后再绑定
什么场景下特别适合用？
不是所有情况都非用不可，但以下几类，事件委托几乎是唯一干净解法：
- 列表/表格行数多（比如 100+ 条），每行都有操作按钮
- 内容由 fetch 渲染、
innerHTML插入或 Vue/React 动态生成 - 频繁增删子元素（如聊天消息流、任务卡片列表）
- 组件需要复用同一套事件逻辑（比如多个 .card 容器都响应点击跳转）
什么时候该收手，别硬套？
委托解决的是“量大且行为相似”的问题，不是万能胶布。如果子元素行为差异太大，强行塞进一个监听器里堆 if/else，反而难读难改。
- 有的点一下跳外链，有的弹窗，有的发 API 请求，还有的要阻止默认行为——建议按行为分组，拆成两三个委托，或回归直接绑定
- 父容器层级太高（比如直接挂到
document），又监听多种事件（click + keydown + input），判断开销会上升，应尽量靠近真实操作区域（例如只在#user-list上处理列表相关 click） - 某些事件不冒泡（如 focus、blur、mouseenter/mouseleave），不能用委托，得另想办法
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
