大表格场景下DOM事件委托与按钮逐个绑定的浏览器资源占用对比

方案选择结论 #

方案1（基于<table>的事件委托）的综合性能远优于方案2，是当前场景下的最优选择

核心逻辑说明（含补充疑问解答） #

1. 浏览器的事件传播本身遵循「捕获-目标-冒泡」的原生机制，事件委托完全依赖浏览器默认的冒泡逻辑实现，不需要为任何子元素额外绑定监听器，不存在你担心的子元素额外监听器开销。
2. 两种方案的实际性能差异在表格行数较多（≥100行）时会非常明显，差异主要体现在三个维度：
   • 加载耗时：方案2需要遍历所有行的所有按钮绑定监听器，行数越多初始化阻塞时间越长；方案1仅需要在<table>上绑定1次监听器，初始化开销几乎可以忽略。
   • 内存占用：方案2会生成与按钮数量对等的监听器实例，占用大量内存，若表格有动态增删行的需求，还需要额外处理监听器解绑，遗漏就会造成内存泄漏；方案1仅占用1个监听器的内存，动态增删行无需任何额外操作。
   • 运行时流畅度：你担心的方案1「无意义触发调用」的开销极低，仅需要在事件冒泡到<table>时，做一次目标元素匹配（比如用event.target.closest('button')匹配按钮，或者匹配按钮的自定义属性如data-btn-type），这层判断的开销远低于大量监听器带来的内存占用开销。

更优的替代优化方案 #

可以在事件委托的基础上做进一步优化，进一步降低运行时判断开销：

• 不要绑定在最顶层的<table>上，绑定到更靠近按钮的公共父容器，比如给所有行最后一个放按钮的单元格统一加类名.action-cell，将监听器绑定在所有.action-cell的公共父级（静态表格也可以直接绑到<tbody>上，比<table>层级更近，冒泡路径更短）
• 给所有按钮统一加自定义属性标识操作类型，比如data-action="edit"、data-action="delete"，匹配时直接判断event.target.dataset.action是否存在即可，不需要遍历DOM找祖先元素，匹配速度更快
• 如果表格使用虚拟滚动实现，事件委托是最优解，天然支持动态渲染的行，不需要每次渲染新行时重复绑定事件

内容的提问来源于stack exchange，提问作者Simon