事件委托通过将子元素的事件监听绑定到父元素来优化性能。1. 减少监听器数量，降低内存消耗；2. 动态添加的子元素无需重新绑定事件；3. 利用事件冒泡机制，由父元素统一处理事件。例如，为列表所有项绑定点击事件时，只需在父元素上绑定一次，通过event.target判断具体触发项。但事件委托依赖事件冒泡，部分事件如focus、blur不支持冒泡，且需复杂判断目标元素，过度委托至顶层还可能影响性能。选择策略包括：选最近父元素、明确目标元素、避免过度委托、考虑事件类型，并权衡性能与代码复杂度。
JavaScript的事件委托，简单来说，就是把子元素的事件监听器绑定到父元素上。这样，当你点击或操作子元素时，实际上是父元素在响应。这能减少内存占用，尤其是在子元素很多的情况下，还能方便动态添加的子元素也能响应事件。
事件委托的核心在于利用事件冒泡机制。当一个事件在DOM树中发生时，它会从触发元素开始，逐级向上冒泡，直到到达根元素。事件委托就是利用这个特性，在父元素上监听子元素的事件。
如何利用事件委托优化性能？
事件委托优化性能的关键在于减少事件监听器的数量。假设你有一个包含100个列表项的无序列表，如果每个列表项都需要绑定一个点击事件，那么就需要创建100个事件监听器。这会消耗大量的内存和CPU资源。
立即学习“Java免费学习笔记（深入）”；
使用事件委托，你只需要在无序列表的父元素上绑定一个点击事件监听器。当用户点击列表项时，事件会冒泡到父元素，然后父元素根据事件的目标（event.target）来判断是哪个列表项被点击了。
下面是一个简单的例子：
- Item 1
- Item 2
- Item 3
在这个例子中，我们只创建了一个事件监听器，但是它可以响应所有列表项的点击事件。如果动态添加了新的列表项，它们也会自动响应点击事件，而不需要重新绑定事件监听器。
事件委托有哪些潜在的问题和限制？
虽然事件委托有很多优点，但也存在一些潜在的问题和限制。
- 事件冒泡的依赖性： 事件委托依赖于事件冒泡机制。如果事件被阻止冒泡，那么父元素就无法监听到子元素的事件。某些情况下，你可能需要显式地允许事件冒泡。
-
事件类型限制： 并非所有的事件都支持冒泡。例如，
focus、blur、load、unload、mouseenter、mouseleave等事件就不支持冒泡，因此无法使用事件委托。 -
目标元素判断的复杂性： 在父元素的事件监听器中，需要判断事件的目标元素是否是期望的子元素。如果DOM结构比较复杂，判断逻辑可能会比较复杂，容易出错。而且，频繁的DOM操作（例如，通过
event.target.classList.contains()来判断元素是否包含某个类名）也会影响性能。 -
过度委托的风险： 如果将事件委托到DOM树的顶层（例如，
document或body），可能会导致不必要的性能损耗。因为所有的事件都会冒泡到顶层，即使这些事件与你的代码逻辑无关。
例如，假设你的代码中有一个全局的事件监听器，用于处理所有的点击事件。如果用户点击了一个与你的代码逻辑无关的元素（例如，一个第三方广告），事件仍然会冒泡到顶层，并触发你的事件监听器。这会浪费CPU资源，并可能导致性能问题。
如何选择合适的事件委托策略？
选择合适的事件委托策略需要综合考虑多个因素，包括DOM结构、事件类型、性能要求和代码复杂度。
- 选择合适的父元素： 应该选择离目标元素最近的父元素进行事件委托。这样可以减少事件冒泡的距离，并减少不必要的事件处理。
-
明确目标元素： 在事件监听器中，应该明确判断事件的目标元素是否是期望的子元素。可以使用
event.target.matches()方法来判断元素是否匹配指定的CSS选择器。 - 避免过度委托： 避免将事件委托到DOM树的顶层。只委托那些确实需要委托的事件。
- 考虑事件类型： 对于不支持冒泡的事件，不能使用事件委托。
- 权衡性能和代码复杂度： 事件委托可以提高性能，但也可能增加代码的复杂度。应该权衡性能和代码复杂度，选择最合适的策略。
一个更复杂的例子，假设你有一个动态生成的表格，需要为每个单元格添加一个点击事件，用于编辑单元格的内容。你可以将点击事件委托到表格元素上，并使用event.target.closest('td')方法来判断事件的目标元素是否是单元格。
| Cell 1 | Cell 2 |
| Cell 3 | Cell 4 |
event.target.closest('td')方法会从目标元素开始，向上查找最近的元素。如果找到了 元素，就说明用户点击了一个单元格，可以执行相应的逻辑。这个方法比使用 event.target.nodeName == 'TD'更健壮，因为它可以处理嵌套在单元格中的其他元素（例如，或）。
