在阅读 StackOverflow 上关于 jQuery 选择器性能的帖子时，我一遍又一遍地阅读同样的内容，说 jQuery 对选择器使用自下而上或从右到左的方法。
举这个例子...
$("#dnsTitle a.save").removeClass("disabled");
根据我一直在阅读的内容，使用它会更好的性能......
$("a.save #dnsTitle").removeClass("disabled");
我遇到的问题是这根本不起作用！有人可以澄清做选择器的真正最佳方法吗？
我正在开发一个现有的项目，该项目有一些非常长的选择器，我正在尽我所能改进它们，但似乎我得到了错误的信息或过时的信息。我正在使用 jQuery 2.0
“Bottom Up/Right to Left/Leaf to Root”的概念仅与选择器解析器的实现有关，与使用中选择器的顺序无关。
从使用的角度来看，选择器是从左到右“读取”的，您的第一个选择器是您的根，随后的选择器是您的后代。返回匹配最后一个选择器的元素。所以：
#dnsTitle a.save- 查找具有 id 的元素，dnsTitle并从那里查找a具有 class 的后代元素save。你最终a得到了 class 的元素save。
a.save #dnsTitle- 查找a具有 class 的元素，save并从中找到 id 为 的后代dnsTitle。你最终得到任何带有 id 的元素dnsTitle
现在从解析的角度来看，有两种常用的方法来解析选择器字符串，它们是“自上而下”和“自下而上”：
自上而下/从根到叶/从左到右
如果您已经学习过数据结构课程，那么这就是您通常解析树的方式。您找到要开始的节点，这将是您的第一个选择器。然后，您逐步找到后续节点。
这种方法的一个问题是它使用递归方法并使用大量内存，尤其是当您的树很大时。此外，回溯问题也是一个问题，因为后续选择器是后代，并且匹配的深度可能会有所不同。下一个选择器可能匹配一个伟大的^N孙子。递归深入 N 步以找到那个伟大的^N 孩子并采取 N 步返回。
自下而上 / 从右到左 / 叶到根
使用这种方法，解析器会查找与最后一个选择器匹配的所有元素，最终得到一个匹配数组。使用该匹配数组，如果它们与后续的先前选择器匹配，则过滤它们。
这种方法的优点是你有一个固定的数组来处理，而不是一个可变深度的树。此外，您正在线性过滤，因为在这种情况下，一个节点只能有一个父节点，而自顶向下处理多个子节点。这也意味着您只需要循环来完成这项工作，而不是递归。一个循环可以遍历每个结果，而另一个嵌套循环遍历每个祖先（如果它与后续的先前选择器匹配）。