要在 jQuery 中选择子节点，可以使用 children()，也可以使用 find()。
例如：
$(this).children('.foo');
给出相同的结果：
$(this).find('.foo');
现在，哪个选项最快或首选，为什么？
问问题
250974 次
7 回答
427
children()仅查看节点的直接子节点，同时find()遍历节点下方的整个 DOM，因此在等效实现的情况下children() 应该更快。但是，find()使用本机浏览器方法，而children()使用在浏览器中解释的JavaScript 。在我的实验中，典型情况下的性能差异不大。
使用哪一个取决于您是只想考虑DOM 中的直接后代还是该节点下的所有节点，即根据您想要的结果选择适当的方法，而不是方法的速度。如果性能确实是一个问题，那么尝试找到最佳解决方案并使用它（或在此处查看其他答案中的一些基准）。
于 2009-03-15T15:47:44.843 回答
181
这个jsPerf 测试表明 find() 更快。我创建了一个更彻底的测试，它看起来仍然好像 find() 优于 children()。
更新：根据 tvanfosson 的评论，我创建了另一个具有 16 级嵌套的测试用例。find() 仅在查找所有可能的 div 时较慢，但在选择第一级 div 时 find() 仍然优于 children()。
当 find() 有超过 100 层嵌套和大约 4000 多个 div 供 find() 遍历时，children() 开始优于 find()。这是一个基本的测试用例，但我仍然认为 find() 在大多数情况下比 children() 快。
我在 Chrome 开发者工具中逐步浏览了 jQuery 代码，并注意到 children() 在内部调用了兄弟 ()、filter()，并且比 find() 执行了更多的正则表达式。
find() 和 children() 满足不同的需求，但是在 find() 和 children() 输出相同结果的情况下，我建议使用 find()。
于 2011-10-07T20:11:23.363 回答
91
这是一个可以运行性能测试的链接。find()实际上比 . 快大约 2 倍children()。
于 2013-08-14T02:19:16.713 回答
25
那些不一定会给出相同的结果：find()将为您提供任何后代节点，而children()只会为您提供匹配的直接子节点。
在某一时刻，find()它要慢得多，因为它必须搜索每个可能匹配的后代节点，而不仅仅是直接子节点。然而，这不再是真的；find()由于使用本机浏览器方法，速度要快得多。
于 2009-03-15T15:49:26.540 回答
14
其他答案均未涉及使用或仅.children()搜索.find(">")父元素的直接子元素的情况。所以，我创建了一个jsPerf 测试来找出，使用三种不同的方式来区分孩子。
碰巧的是，即使使用额外的 ">" 选择器，.find()仍然比;快很多。.children()在我的系统上，是 10 倍。
因此，从我的角度来看，似乎没有太多理由使用过滤机制.children()。
于 2014-12-01T17:43:30.923 回答
3
find()和方法都children()用于过滤匹配元素的子元素，除了前者是向下移动任何级别，后者是向下移动单个级别。
简化：
find()- 搜索匹配元素的孩子、孙子、曾孙……所有级别。children()– 仅搜索匹配元素的子元素（向下一层）。
于 2015-05-04T12:12:34.517 回答
0
很抱歉，我自己的经验与这里的大多数答案都不匹配，所以我认为在这里分享它并建议人们为自己的使用环境进行自己的测试很有趣。
通过在我的脚本$(...).find()的几个地方替换为$(...).children().
项目的实际嵌套非常低（最多 3 层），尽管如此，children() 显然效率更高。
两者都被调用了数千次以检索网格中的信息（由数千个 组成）。目的主要是根据单元格内容中的几件事对单元格/列/行应用一些样式。
使用 Firefox，在替换 find() 之前，网格的加载时间在 2100 到 2400 毫秒之间。在使用 children() 进行更改后，它减少到 1300 到 1500 毫秒之间（因此减少了 30% 到 40% 之间）。
然而，不幸的是，对于 Chrome，它并没有那么令人信服：Chrome 处理完全相同的事情要慢得多（8 秒），而且在此更改前后我没有看到任何明显的性能差异。
于 2022-01-28T13:31:46.223 回答