事件委托能用父元素管住子元素点击是因为浏览器原生支持事件冒泡，子元素click会逐层向上触发至document，父元素在冒泡路径上绑定监听器即可捕获；event.target指向被点击元素，event.currentTarget指向绑定监听器的父容器。
事件委托为什么能用父元素管住子元素的点击
因为浏览器原生支持事件冒泡：子元素触发 click 时，事件会自动沿着 DOM 树逐层向上传到 document。父元素只要在冒泡路径上、且绑了监听器，就能捕获它。
关键不是“父元素多聪明”，而是浏览器强制走这条路径——你没得选，但可以利用它。
-
event.target指向真正被点中的元素（比如某个button.delete） -
event.currentTarget指向你绑监听器的那个父容器（比如ul#task-list） - 两者不同，是委托能区分“谁被点”和“在哪处理”的基础
为什么不能直接给每个子元素 bind click
三个现实问题会立刻浮现：
- 动态添加的节点（如
innerHTML += '<li>...</li>'）不会自动继承监听逻辑，必须手动补绑，极易漏掉 - 列表有 200 项，就创建 200 个
addEventListener，内存占用和初始化时间线性上涨 - 用
removeChild删除节点后，旧监听器若没手动removeEventListener，会滞留在内存里成泄漏源
委托把监听器压到 1 个，所有新增/删除节点天然适配，不用额外干预。
立即学习“前端免费学习笔记（深入）”；
e.target.matches() 和 e.target.closest() 怎么选
目标匹配逻辑写错，委托就形同虚设。这两个 API 是当前最稳的判断方式：
- 用
e.target.matches('button.delete')判断当前点击元素是否**自己就符合选择器**（适合按钮、链接等独立可点元素） - 用
e.target.closest('li')向上找**最近的符合条件的祖先**（适合点击li内任意位置都要响应整个项的场景） - 别用
e.target.className.includes('delete')—— class 可能带空格或多个类名，匹配不可靠 - 别用
e.target.tagName === 'BUTTON'—— 如果按钮里嵌了svg或span，实际target是那个子元素，判断就失效
示例中 e.target.closest('button.delete') 能穿透图标、文字包裹层，比查 class 或 tag 名鲁棒得多。
父容器选 document 还是具体 ul？
选太顶层的容器（比如直接绑在 document 上）看似一劳永逸，实则埋坑：
- 事件要冒泡经过太多层级，路径长，性能略差（尤其低端设备）
- 容易误触——比如你在做弹窗，弹窗外的
document点击要关闭，但委托逻辑又在里头混着处理列表，条件分支一多就互相干扰 - 调试困难：所有委托事件都堆在同一个监听器里，
console.log(e.target)看不出上下文
实操建议始终优先选**离子元素最近的、稳定存在的父容器**，比如 ul#task-list 或 div.todo-container。它在页面加载时就得存在，否则 addEventListener 会静默失败。
委托本身不难，难的是每次加新交互时，是否还坚持收口到同一个监听器里判断意图——而不是随手再 querySelectorAll('.batch-delete').forEach(...) 单独绑一个。这才是维护成本分水岭。
