事件委托通过在父元素绑定单个监听器替代为大量子元素分别绑定，显著减少内存占用；它依赖事件冒泡和closest()精准定位目标元素，适用于动态列表等场景，但不适用于少量静态元素或需精细控制监听器生命周期的情况。
事件委托为什么能减少内存占用
直接给大量元素绑定事件监听器，每个监听器都会在内存中保留一份函数引用和闭包环境。比如动态生成 1000 个 li 并逐个绑定 click，就创建了 1000 个独立监听器；而用事件委托只在父容器（如 ul）上绑定 1 个，所有点击都由它捕获后判断目标，内存开销几乎不变。
常见错误是以为“委托 = 一定更快”，其实如果只有 3–5 个静态元素，委托反而多了一层 event.target 判断，纯属画蛇添足。
- 适用场景：列表项频繁增删、表格行数不确定、无限滚动加载内容
- 不适用场景：固定少量元素、需要精确控制每个元素监听器生命周期（如依赖
removeEventListener） - 注意
event.stopPropagation()会阻断冒泡，导致委托失效——这是调试时最常卡住的地方
如何正确获取被点击的真实元素
委托的核心在于从 event.target 向上查找匹配的选择器，不能直接用 event.target 假设它就是目标元素——用户可能点在 span、img 或空白处。
推荐用 element.closest(selector)，它从当前节点开始向上找，兼容性好（IE 不支持，但现代项目基本可忽略），语义清晰：
立即学习“Java免费学习笔记（深入）”；
ul.addEventListener('click', function (e) {
const item = e.target.closest('li');
if (item) {
console.log('点击了第', Array.from(this.children).indexOf(item) + 1, '项');
}
});
- 避免用
e.target.tagName === 'LI'：太脆弱，无法处理嵌套结构 - 避免手动遍历
parentNode：易漏判、代码冗长 -
closest()返回null表示没匹配到，必须显式判断，否则后续操作会报Cannot read property 'xxx' of null
委托时怎样传入自定义数据
不能在监听器里写死参数（比如 handleClick(id)），因为委托函数是复用的。可靠方式是把数据存在 DOM 上，再读取：
推荐用 data- 属性 + dataset API，比 getAttribute 更安全，自动处理类型转换：
ul.addEventListener('click', function (e) {
const li = e.target.closest('li');
if (li) {
const id = Number(li.dataset.id); // 自动转数字
const status = li.dataset.status; // 字符串
handleItemAction(id, status);
}
});
- 不要用
li.id或li.className存业务数据：语义不符，且 class 名可能被 CSS 框架修改 - 避免在循环中用
let变量闭包传参：委托函数不进循环，这招根本用不上 -
dataset的 key 是驼峰转换的（data-user-id→dataset.userId），拼错就拿不到值
委托后事件对象丢失怎么办
有些库或旧代码会调用 event.preventDefault() 或 event.stopPropagation() 在子元素上，结果父级委托监听器收不到事件——不是委托失效，是事件根本没冒泡上来。
检查路径上任意中间元素是否调用了这两个方法，尤其是第三方组件内部（比如某个 button 组件默认阻止了默认行为）。
- 临时调试可用
console.log(e.bubbles)看事件是否还支持冒泡 - 若必须阻止默认行为但又要让委托生效，改用
e.target.tagName === 'A' && e.preventDefault()，别无脑全拦 - 深层嵌套时，用浏览器开发者工具的 “Event Listeners” 面板直接看哪个节点绑了什么监听器、是否调用了阻止方法
实际项目里，性能提升往往不是来自“少绑几个监听器”，而是避免重复绑定/解绑逻辑、减少 DOM 查询次数、统一处理异步插入的节点——这些细节比“用不用委托”更影响体验。