事件委托是将事件监听器绑定到父元素上，利用事件冒泡和event.target识别实际触发元素，实现一次绑定、动态生效、节省内存。
事件委托就是把 click 绑到父元素上，靠 event.target 找真凶
它不是给每个 li、button 单独加 addEventListener，而是只在它们共有的父容器（比如 ul、div#list）上监听一次。用户点哪个子元素，事件会顺着 DOM 树往上冒泡，父元素捕获后，用 event.target 拿到实际被点击的节点，再做判断和处理。
常见错误现象：
– 动态插入新 li 后点不动，因为没重新绑定事件
– 列表有 200 行，绑了 200 次 click，内存涨、页面卡、DevTools 里一堆监听器
– 用 removeChild 删除元素后，忘了 removeEventListener，悄悄泄漏内存
- 适用场景：待办列表、聊天消息流、分页表格、动态菜单、AJAX 加载后的内容区
- 不适用场景：
focus/blur（不冒泡）、mouseenter/mouseleave（不冒泡）、需要捕获阶段干预的极少数情况 - 必须锚定「最近公共父容器」——太深（如直接选
li的父span）可能没意义；太高（如绑到document）会增加判断开销，也容易被中途stopPropagation()截断
为什么能省内存、扛动态增删？关键在「一次绑定，永久生效」
传统做法：每新增一个按钮，就调一次 btn.addEventListener('click', handler)；删掉时还得手动解绑。而事件委托只需在初始化时对父容器绑定一次，后续所有增删的子元素，只要结构关系不变（仍是该父元素的后代），就天然响应事件。
性能影响很实在：
– 绑定次数从 N 次 → 1 次，减少 DOM 访问和 JS 对象创建
– 内存中事件监听器数量稳定，不会随列表长度线性增长
– 避免频繁绑定/解绑引发的 GC 压力，尤其在滚动加载或实时消息场景下更明显
立即学习“Java免费学习笔记（深入）”；
- 实操建议：优先选语义清晰、生命周期稳定的父容器，比如
<ul id="task-list"></ul>，而不是临时包装的<div> <li>兼容性无顾虑：所有现代浏览器 + IE9+ 都支持事件冒泡，<code>event.target也早已标准化 - 注意别写成
event.currentTarget === event.target判断——那是用来区分“谁绑的”和“谁被点的”，委托场景下二者几乎总不相等 -
目标匹配要精准：别直接用
event.target.classList.contains('delete-btn')，万一用户点的是按钮里的图标或文字节点（textNode），event.target就不是按钮本身。应改用event.target.closest('.delete-btn') -
别让
stopPropagation()断掉链路：如果某个子组件（比如第三方弹窗、富文本编辑器）内部调用了e.stopPropagation()，事件就冒不到你委托的父层了。此时要么协商改用stopImmediatePropagation()（更局部），要么降级为单独绑定 -
别忽略事件委托不覆盖的「伪事件」：例如
input的change要等失焦才触发，但它的冒泡行为正常；而focusin/focusout是冒泡版的focus/blur，可委托，但需注意兼容性写法
怎么写才不容易翻车？三个硬核检查点
事件委托看着简单，但线上 bug 往往出在边界逻辑上。以下三点是高频踩坑位：
真正难的从来不是语法，而是判断「这个交互到底该不该委托」——比如一个带复杂拖拽逻辑的卡片，里面还有开关、下拉、右键菜单，这时候粗暴地把所有事件都扔给外层容器，反而会让逻辑纠缠不清。委托的价值，在于简化重复动作；它的代价，是把判断逻辑集中到了一处。权衡清楚，比写对代码更重要。
