事件委托适用于大量动态增删元素的场景，通过在父容器绑定事件并利用冒泡和e.target.closest()精准捕获目标，避免重复绑定、内存泄漏及重绘时的逻辑耦合。
事件委托不是“必须用”的技巧，而是当你要监听大量动态增删的元素时，它能避免反复绑定/解绑 addEventListener，从而减少内存占用和 DOM 操作开销。
为什么直接给每个子元素绑定事件会出问题
比如一个列表有 200 个 ，你为每个都调用 li.addEventListener('click', handler)：
- 首次渲染就要执行 200 次绑定，JS 执行时间变长
- 后续新增
时，还得再手动绑定一次，容易漏掉 - 删除某个
时，若忘了removeEventListener，就留下内存泄漏风险 - 如果列表支持排序或分页，每次重绘都得重新绑定，逻辑耦合严重
事件委托的核心：利用事件冒泡 + event.target
把监听器放在父容器上（如 event.target 是否匹配目标类型：
document.querySelector('ul').addEventListener('click', function (e) {
if (e.target.tagName === 'LI') {
console.log('点击了 li:', e.target.textContent);
}
});
注意：e.target 是实际被点击的元素（可能是 或 ），所以更稳妥的写法是用 e.target.closest('li') 来向上查找最近的 ：
立即学习“Java免费学习笔记（深入）”；
document.querySelector('ul').addEventListener('click', function (e) {
const li = e.target.closest('li');
if (li) {
console.log('点击了 li:', li.textContent);
}
});
哪些场景适合用事件委托
不是所有点击都要委托——关键看“目标是否动态、是否成批、是否嵌套深”：
- 表格行（
）很多且支持 AJAX 分页 - 聊天消息列表，新消息通过
innerHTML += ...或append()插入- 菜单项由 JS 渲染，且可能频繁切换状态（禁用/高亮）
- 富文本编辑器里对段落、标题等块级元素做统一操作
反例：只有一个按钮、或者按钮极少且永不增删，硬套委托反而多绕一层判断，没收益。
容易踩的坑：委托失效的常见原因
看似简单，但实际调试时经常卡在这几处：
-
event.stopPropagation()在子元素中被调用，阻断了冒泡路径 - 父容器用了
pointer-events: none或visibility: hidden（注意：后者仍可冒泡，前者完全拦截） - 监听的是
ul，但实际点击区域在ul外的空白处，e.target是ul自身，不满足closest('li') - 用
querySelectorAll('li').forEach(...)绑定时没注意 NodeList 是静态的，后续新增的li不会被覆盖
委托真正省事的地方，不在“少写几行代码”，而在于你再也不用操心“这个新插入的按钮有没有绑上 click”。只要结构不变，委托监听器一劳永逸——前提是别在中间层把它掐断了。
- 聊天消息列表，新消息通过
