Javascript 总是对唯一的dom元素使用live（）而不是bind（）的缺点？

在编写jQuery绑定事件时，我通常使用

绑定（

）别名（

单击（）

，

提交（）

，等等）

但是，我越是使用动态生成的内容，我就越觉得它在什么时候

bind（）

不起作用这个问题上模棱两可，最后调试了半个小时，直到我尝试

live（）

，它才起作用

在ID选择器的参数内（如“

#foo

”，而不是

.class

或元素

（“输入”）

）：

对于这些类型的绑定，除了缺少方便的别名之外，总是使用

live（）

而不是

bind（）

还有什么缺点吗？因为只有一个DOM元素绑定到一个特定的ID

===========

---

编辑：我不是问

bind（）

和

live（）

之间有什么区别；这已经包括在内了。我想问的是，默认情况下只使用live（）有哪些缺点，因为这样做的诱惑是在不能错误选择的情况下（即，当您使用

#uniquedoElement

时），避免思考

绑定（）

何时不合适

bind的问题是，必须在元素出现在页面上后调用bind。。通常，人们在文档上调用bind ready，以便将行为附加到页面上的元素。如果之后通过javascript将元素添加到页面中，则需要对添加的新元素应用相同的绑定调用，这通常很麻烦，因此可以使用.live

.live使用事件委托，这意味着jquery不会将函数处理程序绑定到页面上的特定元素，而是管理所有不同的实时调用，这样，当您执行某种类型的操作（存在实时处理程序）时，它将检查您对其执行该操作的元素是否与给定的选择器匹配（我相信这就是它的工作原理）。我猜它会将事件添加到文档正文中（用于单击/鼠标操作）。。 我不确定具体细节，但我知道如果你什么都使用live，你会有一些奇怪的行为。通常，如果你有大量的元素，你会应用一些行为，或者你会通过javascript动态添加这些元素，那么最好使用live

---

阅读文档了解更多信息：

这是一种平衡行为。

Live（）

将事件绑定到文档并搜索激发的事件目标。Live的优点（即，通常情况下，事件委派）是，对于无限多的参数，只绑定一个事件处理程序。

Bind（）

将事件处理程序直接附加到元素本身，因此如果表中有1000行，并且运行

$（'tr'）.bind（…）

，则将绑定1000个事件处理程序。如果执行

$（'tr'）.live（…）

，则只绑定一个事件处理程序

您可以在中间使用.ReaveTo（），因为它指定了事件的上下文，所以它不同于它，因此它不会总是火，因此更有效。使用表示例，您将使用<代码> $（“表”）。委托（TR）、“点击”、“函数”（{…}）；。您获得了bind和live的优点，同时也获得了最小的缺点：您绑定了一个事件处理程序，它是未来的证明（仅包含该表的上下文），您不需要遍历整个dom来查找“tr”元素

绑定、生活和委派都有自己的位置

另外，另一方面，委托只是执行$（'tr'，$（'table'）[0]）.live（）的另一种方式，但这看起来很难看，因此委托是存在的。

委托的主要缺点是重量（这在使用大量处理程序时适用），因为它将事件处理程序附加到

文档中，默认情况下事件会在那里冒泡（它如何工作的整个基础）这意味着当事件到达文档时，必须检查一些事情：


我是否有此事件类型的任何事件
如果是，事件来自的元素是否与这些处理程序的任何选择器匹配

第一个非常便宜，第二个不便宜。让我们举一个最常见的例子，
单击
事件。一个
单击
事件气泡，到目前为止还不错。假设我们在
文档
上注册了一个或多个
单击
事件处理程序……现在我们必须循环所有这些处理程序并比较它们的选择事件所来自的元素的系数，处理程序越多，成本就越高，每次单击都会发生，这是迄今为止最大的性能损失

还有其他问题，例如附加/删除处理程序，但这是对处理程序的管理……将处理程序与直接调用进行比较时，上述性能问题是主要问题。
使用live（）会降低性能…这很有帮助..阅读评论bind用于当对象已经存在时，live将自动绑定到调用live后创建的新对象。@John Hartsock你真的应该回答这个问题…我本来打算回答的，但后来我阅读了链接的评论，现在觉得毫无意义：P.@Domenic。基本上问题已经解决了在前面的一个问题中得到了回答。我只是简单地评论了原始问题的链接，然后投票赞成close@JohnHartsock我不认为它完全回答了这个问题。nickf最接近于回答我想要的问题（谈论它与文档的绑定，以及可能的性能问题），但仅仅因为他简单地解决了这个问题并不意味着问题已经得到了回答。IMO委托总是比。live好，原因有二：1.你可以更具体地说明根注释在哪里使用事件委托，2.它不会不必要地在所有元素上循环