事件委托的核心原理是利用事件冒泡机制，将事件监听器绑定在父元素上，通过event.target.closest()和matches()精确识别目标元素，避免为动态元素重复绑定，但不适用于focus/blur等不冒泡事件。
事件委托的核心原理是什么
事件委托依赖于事件冒泡机制：子元素触发的事件会逐级向上传播到父元素。只要把监听器绑定在父节点上，就能捕获所有后代元素的同类事件，无需为每个子元素单独绑定 addEventListener。
典型适用场景是动态增删的列表项、表格行、菜单项等——这些节点可能随时被 JS 创建或移除，直接绑定事件容易漏绑或重复绑定。
怎么写一个可靠的事件委托监听器
关键在于正确判断 event.target 是否匹配目标元素，而不是盲目处理所有冒泡上来的点击。
- 用
event.target.matches(selector)做精确判断（支持 CSS 选择器，如"button.delete"或"li[data-id]"） - 避免用
className或tagName硬比对，易受类名拼写、大小写、多类名干扰 - 注意事件源可能是文本节点（
event.target是#text），需向上查找最近的元素节点，可用event.target.closest(selector) - 委托容器不能是
document或body除非必要——层级太深会增加冒泡开销，也影响语义隔离
const list = document.getElementById('task-list');
list.addEventListener('click', function (e) {
const item = e.target.closest('li[data-id]');
if (!item) return;
const id = item.dataset.id;
if (e.target.matches('button.delete')) {
deleteTask(id);
} else if (e.target.matches('input[type="checkbox"]')) {
toggleDone(id, e.target.checked);
}
});
哪些情况不适合用事件委托
不是所有事件都适合委托，尤其要注意以下限制：
立即学习“Java免费学习笔记（深入）”；
-
focus、blur、mouseenter、mouseleave不冒泡，无法委托 —— 必须直接绑定在目标元素上 - 需要精确控制
event.stopPropagation()的场景，委托后拦截位置变高，可能破坏原有逻辑流 - 高频事件如
mousemove、wheel，委托虽可行，但频繁触发closest()和matches()可能引发性能抖动，建议节流 + 直接绑定到具体区域 - 元素层级极深（比如嵌套 20+ 层），冒泡路径长，委托响应延迟略明显，此时局部委托（如每组卡片一个容器）比全局委托更稳
委托后如何安全地移除监听器
事件委托本身不增加移除难度，但容易忽略「函数引用一致性」这个前提：
- 必须用同一个函数引用调用
removeEventListener，匿名函数无法移除 - 推荐把处理函数声明为具名函数或变量，方便复用和解绑
- 如果用
once: true选项，委托监听器执行一次后自动销毁，无需手动清理 - 组件卸载时（如 React useEffect cleanup、Vue onUnmounted），务必调用
removeEventListener，否则形成内存泄漏
function handleClick(e) {
// ...处理逻辑
}
list.addEventListener('click', handleClick);
// 卸载时
list.removeEventListener('click', handleClick);
实际项目中最容易被忽略的是 closest() 和 matches() 的兼容性边界——IE 不支持，若需兼容，得用 polyfill 或降级为遍历 parentNode；另外，委托容器若被 innerHTML = '' 清空，监听器还在，但子节点全部丢失，这点和直接绑定行为不同，需心里有数。 
