事件委托是基于事件流（捕获→目标→冒泡）、DOM结构和事件对象三者理解后的自然选择，依赖冒泡机制，通过父容器监听、event.target精准匹配子元素实现高效动态绑定。
事件委托不是“学会一个技巧”，而是把事件流、DOM结构、事件对象三者串起来理解后的自然选择。入门门槛低，但真正用稳、用对、能排查问题，得踩过几个典型坑。
先搞懂事件流：冒泡不是bug，是工具
点击一个按钮，事件不会只停在按钮上。它会先从document往下“探路”（捕获阶段），再落到按钮本身（目标阶段），最后从按钮往document“回传”（冒泡阶段）。浏览器默认只响应冒泡阶段的监听器——这正是事件委托能工作的前提。
关键要分清两个东西：
- event.target：用户真正点中的那个元素（比如你点的是列表里的某个删除图标）
-
this 或 event.currentTarget：当前执行处理函数的那个元素（比如你绑在
- 上的监听器，this就是这个
- ）
写错判断逻辑，比如用this.tagName === 'LI'去筛选，就会失效——因为this永远是父容器，不是子项。
动手写一个最小可运行委托：三步闭环
别一上来就套框架或封装库，用原生代码走通一次完整链路：
- 选一个稳定存在的父容器（比如id="comment-list"的）
- 用addEventListener绑定click，第三个参数用默认false（即冒泡阶段）
- 在回调里用if (e.target.matches('button.delete'))做精准匹配，再取e.target.dataset.id拿数据标识
这样写比tagName判断更健壮，也兼容未来加class或换标签的改动。
动态内容场景下，委托不是“可选项”，是“必选项”
后台管理系统里，表格翻页、搜索过滤、无限滚动加载新行——这些操作都不会重新刷新页面，但会反复清空再插入DOM。如果每个新
- 都单独绑click，老节点的监听器没清理干净会内存泄漏，新节点又容易漏绑。
委托直接绕过这个问题：只要父容器不销毁，监听器就一直有效。哪怕你innerHTML整段替换子节点，也不影响事件响应。
注意一个细节：用innerHTML清空容器时，原来绑定在子元素上的监听器会随节点一起被回收；但委托绑在父容器上，完全不受影响。
进阶意识：什么时候不该用委托？
委托高效，但不是万能解法。以下情况建议回归直接绑定：
- 元素数量极少（比如固定5个导航tab），委托带来的抽象成本高于收益
- 需要精确控制捕获阶段行为（如全局快捷键拦截），委托绑在冒泡阶段无法提前介入
- 子元素事件逻辑差异极大，判断分支臃肿（比如一个容器里既有编辑、又有导出、还有拖拽），不如拆成多个委托或独立监听
熟练的关键，是知道“为什么选它”，也清楚“为什么这次不选它”。
