事件委托是利用事件冒泡，将子元素事件监听统一绑定到稳定父元素上，通过event.target匹配目标节点执行逻辑；它节省内存、适配动态内容、降低初始化开销，但focus/blur等不冒泡事件不适用。
事件委托是什么？
事件委托是利用事件冒泡机制，把原本要绑定在多个子元素上的事件监听器，统一移到它们的共同父元素上。浏览器触发子元素事件后，事件会逐级向上冒泡到父元素，这时在父元素上判断 event.target 是哪个真实点击/交互的子节点，再执行对应逻辑。
为什么用 addEventListener 绑定在父元素就能捕获子元素事件？
因为绝大多数 DOM 事件（如 click、input、keydown）默认支持冒泡。只要不调用 event.stopPropagation()，事件就会从目标元素一路传到 document。
实操建议：
- 父元素必须是子元素的**稳定祖先**——不能频繁被销毁重建，否则监听器失效
- 避免委托到
document或body上做精细操作，定位成本高且易受其他脚本干扰 - 用
event.target.matches('button.delete')而不是手动解析className或tagName，更可靠
const list = document.getElementById('task-list');
list.addEventListener('click', function (e) {
if (e.target.matches('button[data-action="delete"]')) {
const taskId = e.target.dataset.id;
deleteTask(taskId);
}
});
它怎么提升性能？关键在三处节省
不是“委托本身快”，而是规避了三种低效模式：
立即学习“Java免费学习笔记（深入）”；
-
内存占用减少：100 个按钮各绑一个
click监听器 → 1 个监听器 + 1 次条件判断 -
动态内容友好：后续用
innerHTML或appendChild新增的子元素，无需重新绑定事件 -
初始化开销下降：省去遍历节点、调用
addEventListener的循环，尤其在渲染大量列表时明显
注意：如果父元素层级过深（比如离目标元素隔了 5 层），冒泡路径变长，但实际性能影响微乎其微；真正拖慢的是监听器内部逻辑写得重，而不是冒泡本身。
哪些情况不适合事件委托？
不是所有事件都适合，也不是所有结构都合适：
-
focus、blur、mouseenter、mouseleave不冒泡，无法委托（可用focusin/focusout替代 focus/blur） - 子元素需要各自独立的
event.preventDefault()行为，且逻辑差异极大，委托后判断分支太多，反而难维护 - 父容器设置了
pointer-events: none或 CSScontain: layout等可能截断事件流的样式
委托失效时最常被忽略的一点：监听器绑定后，父元素被 JS 清空（如 innerHTML = ''）或替换成新 DOM，老监听器就丢了——得确保父容器生命周期比子元素长。
