事件委托能解决动态元素绑定失效问题，因其在父元素监听冒泡事件，不依赖子元素初始存在；动态插入的子元素触发事件仍可被捕获，避免重复绑定与内存浪费。
事件委托为什么能解决动态元素绑定失效问题
因为事件委托不依赖子元素是否已存在，它只在父元素上监听冒泡上来的事件。只要父元素在页面加载时就存在，后续用 innerHTML、appendChild 或框架（如 React/Vue）动态插入的子元素，点击时事件照样会冒泡到父层，被正常捕获。
常见错误现象是：给每个 li 单独绑 addEventListener('click', ...)，但新增的 li 点击无反应——这不是“没绑上”，而是根本没执行那行绑定代码。
- 动态添加后必须重新遍历所有
li并手动绑定，极易遗漏或重复绑定 - 若用
document.write或替换整个父容器 innerHTML，原有绑定全部丢失 - 大量元素时，每个
li持有独立函数引用，内存占用线性增长
怎么写一个可靠的事件委托监听器
核心就三步：选对父容器、监听冒泡阶段、精准识别目标元素。不要直接监听 document，除非真没更近的稳定父级；也不要只靠 event.target.tagName 判断，得兼顾大小写和文本节点干扰。
推荐写法：
立即学习“前端免费学习笔记（深入）”；
const list = document.getElementById('todo-list');
list.addEventListener('click', function(e) {
// 防止点击到文本节点或空白区域
const target = e.target.closest('button.delete');
if (target) {
const item = target.closest('li');
item?.remove();
}
});
-
e.target.closest('button.delete')比e.target.classList.contains('delete')更鲁棒，能穿透嵌套结构 - 避免用
nodeName === 'LI'，因为e.target可能是span或input；用closest()向上找最近匹配项 - 父容器必须在脚本执行时已挂载 DOM，否则
addEventListener会静默失败
批量操作（如“删除已完成”）和单条操作能否共存
完全可以，而且应该共存——它们本质都是对同一组冒泡事件做不同条件分支。关键不是“能不能”，而是“怎么分清意图”。别为每种操作单独绑一个事件监听器，统一收口到一个 handler 里判断更清晰、易维护。
典型场景中，你可能同时响应：
- 点击
li本身 → 切换完成状态（加/删completedclass） - 点击内部
button.delete→ 删除该项 - 点击顶部
button#batch-delete→ 批量清理
做法是：把批量按钮也放进同一个父容器（比如包进 ul 外层的 div），或单独给它绑事件（因为它不属列表项，无需委托）。真正需要委托的，只是那些会动态增删的子项。
容易被忽略的兼容性和边界情况
closest() 在 IE 中不支持，但不用立刻 polyfill——如果项目已用现代构建工具（Vite/Webpack），可配 core-js 自动注入；若需原生支持 IE11，改用 while 循环向上遍历 parentNode 并比对 className 或 dataset。
另一个隐形坑是：事件代理后，e.preventDefault() 必须在目标元素上生效，而不是父容器。比如表单内按钮被委托了，但你想阻止默认提交，就得确保 e.target 是那个 button，且调用 e.preventDefault() 位置正确。
最常漏掉的一点：委托监听器一旦绑定，就长期存在。如果父容器被整个移除又重建（比如 SPA 路由切换重绘），旧监听器不会自动销毁，可能造成内存泄漏或重复触发——务必在容器卸载前用 removeEventListener 清理，或使用事件委托到更稳定的宿主（如 document，但要加条件过滤）。
