别再给每个按钮单独绑事件了：JS 事件委托的封装进阶

前端开发中，面对一个长列表，里面几十个条目都要处理删除、编辑交互，如果遍历每个子元素去 addEventListener，不仅代码冗余，还会造成性能浪费。事件委托是标准解法，但直接把 ul.addEventListener('click', handle) 写在业务代码里，往往容易埋下隐患。

真正的痛点不在“能不能用”，而在“好不好维护”。当页面结构稍变，或者子元素嵌套层级不定时，判断 e.target 是否命中目标就成了一场灾难。比如你只想监听到 .btn-delete 的点击，但用户实际点的是里面的 <i> 图标，原生逻辑很容易失效。

这时候就需要一套可复用的委托封装方案。核心思路是将事件映射关系提取出来，而不是让每个组件去关心如何绑定。我们可以构建一个轻量级 Manager 类，它负责管理根节点和事件类型。

关键优化点在于选择器的智能匹配。利用现代浏览器的 element.closest() 方法，可以从点击位置向上查找符合 CSS 选择器的最近祖先元素。这意味着无论内部嵌套多少层标签，只要找到最近的匹配项就能触发回调，彻底解决了 DOM 结构微调导致事件丢失的问题。

// 简化的核心逻辑示意
const delegate = (container, eventsMap) => {
  container.addEventListener('click', e => {
    Object.entries(eventsMap).forEach(([selector, handler]) => {
      const target = e.target.closest(selector);
      if (target && container.contains(target)) {
        handler.call(target, e);
      }
    });
  });
};

除了匹配逻辑，生命周期管理同样重要。很多项目中，事件绑定后没解绑，单页应用路由切换时容易造成内存泄漏。在封装时要暴露 off 或 destroy 方法，确保组件卸载时能自动移除监听器。如果是 Vue 或 React 环境，配合 Hooks 或 Lifecycle 钩子使用效果更佳。

还有一点常被忽视：同一容器上存在多个同名事件。封装时建议支持多处理器注册，避免覆盖原有逻辑。通过数组存储回调函数，实现中间件式的处理流程，这样后续扩展权限验证、日志记录等功能都不需要改动底层结构。

当然，封装不是越复杂越好。对于简单的静态页面，原生写法效率最高。这套方案更适合大型后台管理系统或长期迭代的项目。合理运用委托封装，能让你的代码库在面对频繁交互变更时，依然保持清爽和稳定。下次重构列表组件时，不妨试试把事件逻辑独立出去，你会发现调试起来顺畅得多。