这两个都是有效的。

前者适用于动态添加的元素。您使用document是因为您将事件委托给文档对象的子对象，因此事件会冒泡到文档级别。选择最接近的父级也更方便（并且在加载时父级必须存在于页面上）。

后者仍然有效，并且是将事件简单地绑定到特定元素的首选方式。

我个人不建议通过document对象进行委托，而是推荐页面加载时存在的最接近的父对象。

以下是on().

这不是真的。

这两行完全是两件不同的事情。

第一个是带有选择器的委托事件，".areaCodeList a"而第二行是附加到".areaCodeList a"元素的事件。

".areaCodeList a"尽管在执行该行时它在 DOM 中，但委托事件将触发每个元素。

无论如何，document根本不建议将委托事件附加到。如live文档中所述：

由于所有 .live() 事件都附加在文档元素上，因此事件在处理之前采用最长和最慢的可能路径

请阅读on 文档：

事件处理程序仅绑定到当前选定的元素；当您的代码调用 .on() 时，它们必须存在于页面上。为确保元素存在并且可以被选择，请在文档就绪处理程序中为页面上 HTML 标记中的元素执行事件绑定。如果将新 HTML 注入页面，则在将新 HTML 放入页面后选择元素并附加事件处理程序。或者，使用委托事件附加事件处理程序，如下所述。

委托事件的优点是它们可以处理来自稍后添加到文档的后代元素的事件。通过选择在附加委托事件处理程序时保证存在的元素，您可以使用委托事件来避免频繁附加和删除事件处理程序的需要。例如，如果事件处理程序想要监视文档中的所有冒泡事件，则此元素可以是模型-视图-控制器设计中视图的容器元素。在加载任何其他 HTML 之前，文档元素在文档的头部可用，因此可以安全地在那里附加事件，而无需等待文档准备就绪。
...
...

我认为你混淆了几个概念。不建议绑定到文档元素，但是有时您想要这样做，例如将事件绑定到动态添加的元素时。

所有这些似乎都不清楚，所以这里是第一个示例，它直接使用类选择器并绑定单击事件，在事件绑定后稍后动态插入元素。正如你所看到的，事件永远不会被触发，因为我们选择了一个在事件绑定时不存在于 DOM 中的元素。这相当于一个.click

现在看第二个例子。在这里您可以看到我们将根元素定义为document. 这意味着单击事件将一直向上冒泡到 DOM 树，然后如果被单击的元素具有动态类，则触发。这相当于.live

现在，如果一个例子中，在结合事件的元素存在于DOM的时候，该代码会工作得很好，你可以看到在这里。

话虽如此。这是文档中的一个例外，它阐明了上述行为。

事件处理程序仅绑定到当前选定的元素；当您的代码调用 .on() 时，它们必须存在于页面上

所以，总而言之。document当您确定您选择的元素没有父元素时，请使用该元素，该元素保证在绑定事件时位于 DOM 中。如果存在父元素，则使用它而不是document元素。这样事件就不必一直向上冒泡document，它只需要传播很短的距离。

对此没有任何“推荐”。第一个片段设置了一个“委托”事件，后者是一个“直接”事件。的文档on()深入解释了这些。

当您需要侦听尚不存在的元素的事件时，委托事件是必要的 - 例如，将在 AJAX 调用之后动态创建的元素。它们有时也可以在性能方面更好 - 与 1000 个按钮相比，您需要更少的内存来将“真正的”事件处理程序附加到文档对象。

我会说，如果可以的话，仍然最好使用直接事件处理程序，或者将委托事件附加到尽可能接近真实事件源的元素。将所有事件处理程序放在文档对象上可能会降低性能 - 您必须匹配针对所有选择器触发的每个事件。如果您需要阻止事件冒泡，也可能需要它 - 如果所有事件都被捕获在文档中，那么它们已经冒泡了。

实际上的情况下的最佳解决方案，例如，这是不使用$(document)既不像的特定元件$("selector")。

最好的方法是使用元素的容器并在 on 函数中绑定元素选择器。通过这样做，您可以避免不必要的事件冒泡到文档中。

所以代码应该是这样的：

$("this_is_the_container").on('event','my_element_selector',function(){
// do some stuff here
})