children()只查看节点的直接子节点，而find()则遍历节点下面的整个DOM，因此给定等效的实现，children()应该更快。但是，find()使用本机浏览器方法，而children()使用在浏览器中解释的JavaScript。在我的实验中，在典型情况下没有太大的性能差异。

使用哪一种方法取决于您是只想考虑DOM中的直接子代节点还是该节点之下的所有节点，也就是说，根据您想要的结果选择适当的方法，而不是方法的速度。如果性能确实是一个问题，那么尝试找到最佳解决方案并使用它(或在其他答案中查看一些基准测试)。

它们不一定会得到相同的结果:find()会得到任何后代节点，而children()只会得到匹配的直接子节点。

在某一点上，find()要慢得多，因为它必须搜索每个可能匹配的后代节点，而不仅仅是直接子节点。然而，这已不再是事实;由于使用本机浏览器方法，Find()速度更快。

这个jsPerf测试表明find()更快。我创建了一个更彻底的测试，看起来find()仍然优于children()。

更新:根据tvanfosson的评论，我创建了另一个包含16层嵌套的测试用例。Find()只是在查找所有可能的div时较慢，但Find()在选择第一级div时仍然优于children()。

当有超过100层嵌套和大约4000+ div需要find()遍历时，Children()开始优于find()。这是一个基本的测试用例，但我仍然认为find()在大多数情况下比children()更快。

我在Chrome开发者工具中逐步通过jQuery代码，并注意到children()内部调用sibling()， filter()，并且比find()通过更多的正则表达式。

find()和children()满足不同的需求，但在find()和children()输出相同结果的情况下，我建议使用find()。

这里有一个可以运行的性能测试链接。Find()实际上比children()快2倍。

其他答案都没有涉及使用.children()或.find(">")只搜索父元素的直接子元素的情况。因此，我创建了一个jsPerf测试来找出答案，使用三种不同的方法来区分孩子。

事实上，即使在使用额外的">"选择器时，.find()仍然比.children()快得多;在我的系统中，是10倍。

因此，从我的角度来看，似乎根本没有太多理由使用.children()的过滤机制。

find()和children()方法都用于过滤匹配元素的子元素，只是前者向下移动任何一层，后者向下移动一层。

简化:

Find()—搜索匹配元素的子、孙、曾孙…各层向下。 Children()—只搜索匹配元素的子元素(向下一层)。

很抱歉，我自己的经验与这里的大多数答案不匹配，所以我认为在这里分享它很有趣，并建议人们根据自己的使用环境进行自己的测试。

通过在脚本$(…).find()的几个地方替换$(…).children()，我获得了大约40%的性能。

项目的实际嵌套非常低(最多3层)，尽管如此，children()显然更有效。

这两种方法都被调用了数千次，以检索网格(由数千个)中的信息。其目的主要是根据单元格内容中的一些内容对单元格/列/行应用一些样式。

在替换find()之前，Firefox的网格加载时间在2100到2400ms之间。在对children()进行更改之后，它被减少到1300到1500ms之间(因此减少了30%到40%)。

然而，对于Chrome来说，不幸的是，这并不是那么令人信服:Chrome处理完全相同的事情要慢得多(8秒)，而且我没有看到这个变化前后有任何明显的性能差异。