Question

如果我有一个包含删除记录链接的表格，这是连接点击事件的最佳方式？这些在引擎盖下评估相同吗？

$("#table").on("click", ".delete", function(){
   //do stuff
});

或

$("#table .delete").click(function(){
   //do stuff
});

Answer 1

不，他们没有。

在你使用它们的方式......

.on() 您使用它的方式（委派），可以节省您在附件和内存中的周期，因为它实际上并不会在那一刻附加事件，因为它提供了一个动态元素，事件也应用于未来的元素。

.click()将在执行时节省周期，因为它在那个时刻明确地将事件附加到每个匹配元素，但实际上，这将是我寻找瓶颈的最后一个地方。

Answer 2

这就像询问int中更快string或C#的内容。每种类型都有它的用途......
这不是关于哪个更快，而是关于什么时候使用。

on允许您将事件附加到动态添加的元素，click则不会。

如果您没有“动态添加的元素”，请使用点击，否则请使用on。

Answer 3

click比on更快，因为它会直接将事件附加到on附加#table上的事件并查找.delete的元素上用于触发事件的元素，因此在触发click事件之前会涉及一些代码执行。

尽管您看不出任何差异，但差异可以忽略不计。

如果您使用on，则只有一个事件处理程序足以处理.delete内的任意数量的#table元素，其中click将附加到每个元素.delete元素在内存利用方面更好on。

Answer 4

在这种特殊情况下，.click(...)将（可能）更慢，因为它需要遍历每一行和每个与选择器匹配的单元格，并将处理函数附加到每一个。在这种特殊情况下，on(...)可能更快，因为它将处理程序附加到表，而不是附加到具有.delete类的每个元素。

话虽如此，在选择这两者时需要考虑一些事项：

你的选择器有多复杂？如果您正在执行$('#rootItem').on('click', '.foo .bar.baz .bum', function() { /* do stuff*/ })，这将比$('#rootItem').on('click', '.foo', function() { /* do stuff*/ })慢，因为选择器在前一种情况下更复杂。在这种情况下，为附件付出代价可能更有意义，并使用click(...)来节省评估#rootItem内每次点击的运行时成本，看它是否与选择器匹配{{} 1}}。像你这样的简单单一类选择器（'.foo .bar.baz .bum'）会表现得很好。
内容会动态变化吗？如果是这样，您将负责在每个动态添加的项目上调用'.delete'。 click(...)函数可以更好地处理这个问题，只要您的“外部”选择器（在这种情况下为on(...)）不指向将动态添加的元素。将'#table'替换为'#table'，并动态添加一个包含类'.table'的新表，并且新添加的表将不会在您对{{1}的初始调用时附加事件处理程序}}。