事件委托是利用事件冒泡机制将监听器绑定在父元素上以统一管理子元素事件的策略。适用于动态增删、数量多且行为一致的子元素场景，可减少内存占用、提升维护性，但需注意父容器稳定性、选择合适的冒泡事件及避免过度使用。
事件委托（Event Delegation）不是一种新事件，而是利用 事件冒泡 机制，把事件监听器绑定在父元素上，由它统一捕获并判断真正触发事件的子元素——本质上是“以一管多”的 DOM 事件管理策略。
什么时候该用 addEventListener + event.target 做委托？
当你遇到以下任一情况，就该立刻考虑事件委托：
- 列表项（
<li>）、表格行（<tr>）、卡片容器（<div class="card">）数量超过 10 个，且行为一致（比如都响应点击） - 内容通过
fetch或innerHTML动态插入，新元素无法提前绑定事件 - 频繁增删子元素（如 todo 列表的添加/删除），每次操作后不想重复调用
addEventListener - 发现 DevTools 的 “Listeners” 面板里同类型事件监听器爆炸式增长（比如 200+ 个
click）
为什么不能直接给每个子元素绑事件？
问题不在“能不能”，而在“值不值得”——尤其在现代 SPA 场景下：
-
内存开销真实存在：1000 个
<li>各绑一个click回调，就是 1000 个函数实例 + 1000 个事件监听器；委托到<ul>上，只保留 1 个 -
动态元素会彻底失效：用
document.createElement插入新<li>后，它压根没有事件监听器，除非你再手动addEventListener一次 - 维护成本翻倍：改个点击逻辑？得遍历所有子元素重新绑定；而委托只需改父元素上的一个回调
最简可用的委托写法和常见翻车点
核心就三步：选对父容器 → 监听冒泡事件 → 用 event.target 精准匹配目标。但细节决定成败：
立即学习“Java免费学习笔记（深入）”；
- 必须确保父容器**稳定存在且不会被替换**（别选
document.body当委托根，除非真没别的） - 用
event.target.matches('selector')判断，别用event.target.className或event.target.tagName硬比——容易漏匹配或误匹配 - 注意事件类型是否支持冒泡：
focus/blur默认不冒泡，得用focusin/focusout - 避免过度委托：如果只有 2–3 个按钮，还硬套委托，属于“杀鸡用核弹”
const list = document.querySelector('ul');
list.addEventListener('click', (e) => {
if (e.target.matches('li.delete-btn')) {
// ✅ 安全匹配：只响应 class="delete-btn" 的 li
e.target.closest('li').remove();
}
});
真正难的不是写对这一段代码，而是判断「这个交互到底该不该委托」——比如一个带复杂动画的悬停菜单，委托后 mouseenter 冒泡行为可能和预期不符；这时候宁可放弃委托，老老实实遍历绑定。
