事件委托是将事件监听器绑定到父元素，利用冒泡机制统一处理子元素事件；它减少内存占用、提升动态内容性能，并简化dom变更管理，但需用closest()精准匹配目标且避开不适用场景。
事件委托是什么：用一个监听器管住一群元素
事件委托不是给每个子元素单独绑事件，而是把事件监听器放在它们的共同父元素上，靠事件冒泡机制来统一处理。比如页面里有 100 个 ，你不用调用 100 次 addEventListener，只在它们的
父容器上监听一次 怎么写才可靠：别只靠
click，再通过 event.target 判断点的是哪个按钮。
为什么能提升性能：减少内存占用和绑定开销
每次调用 addEventListener 都会创建一个事件监听器对象，占用内存；大量绑定还会拖慢初始渲染。事件委托把监听器数量压到 1 个，尤其适合动态增删子元素的场景（比如列表分页、聊天消息流）：
- 新插入的子元素自动“继承”事件响应能力，无需重新绑定
- 移除整个父容器时，只需解绑 1 个监听器，避免漏掉子元素导致内存泄漏
- DOM 变更频繁时，避免反复调用
removeEventListener或忘记清理
怎么写才可靠：别只靠 event.target 直接判断
event.target 是实际被点击的最深节点，但它可能是子元素里的 、 或文本节点，直接用 event.target.tagName === 'BUTTON' 容易失效。
推荐做法是用 event.target.closest() 向上查找最近的匹配祖先：
立即学习“Java免费学习笔记（深入）”；
parent.addEventListener('click', (e) => { const btn = e.target.closest('button'); if (btn) { console.log('点中了按钮:', btn.dataset.id); } });注意点：
-
closest()在 IE 中不支持，需加 polyfill 或改用遍历parentnode - 如果父容器本身也可能被误点（比如 padding 区域），确保 css 的
pointer-events: none没乱用 - 避免在委托监听器里做重操作（如 DOM 批量更新），否则一次冒泡就卡住整个交互
哪些情况不适合用事件委托
不是所有场景都适用。典型反例：
- 需要捕获阶段行为（如阻止默认动作）且子元素层级太深，冒泡延迟不可控
- 子元素需要各自独立的事件选项（比如一个要
{ once: true }，另一个要{ passive: true }） - 父容器本身监听了同类型事件且调用了
e.stopPropagation()，会截断冒泡路径 - 使用了 Shadow DOM 且跨影子边界——
event.composedPath()要配合处理，不能只信target
真正省事的前提是：结构稳定、语义清晰、冒泡路径可控。否则，硬套委托反而让逻辑更难 debug。