性能问题：存储对DOM元素的引用与使用选择器的引用
因此，在我的应用程序中，用户可以在某些div标签内创建一些内容，每个内容，或者我称之为“元素”的内容都有自己的对象。 目前我使用一个函数来计算元素放置在里面的原始div标签使用jquery选择器，但我想知道在性能方面，只要元素有一个div标签的引用就不是更好已创建，而不是以后计算？ 所以现在我使用这样的东西：
$('.div[value='+divID+']') 但是当我创建元素时，我可以将引用存储在元素中。 这对表现会更好吗？
如果你有很多这些绑定，那么存储对它们的引用是个好主意。 正如评论中所提到的，变量查找比在DOM中查找更快 – 特别是使用您当前的方法。 jQuery选择器比纯DOM替代品慢，而且特定的选择器将非常慢。
这是一个基于epascarello的测试，显示了jQuery，DOM2方法和参考资料之间的区别： http ： //jsperf.com/test-reference-vs-lookup/2 。 变量赋值按预期超快。 此外，DOM方法以同样大的优势击败jQuery。 请注意，这是以Yahoo的主页为例。
另一个考虑因素是DOM的大小和复杂性。 随着这种增加，参考缓存方法仍然变得更加有利。
与每次查找相比，局部变量将超快。 测试certificate它 。
jQuery是一个构建和返回对象的函数。 那部分并不是非常昂贵，但实际的DOM查找确实涉及相当多的工作。 对于匹配现有DOM方法（如getElementById或getElementsByClassName）的简单查询，开销不是那么高（在IE8中不存在，所以它真的很慢）但是区别在于工作（构建包装DOM访问的对象）方法）并且几乎没有工作（引用现有对象）。 如果您计划重新使用它们，请始终缓存选择器结果。
此外，你正在使用的xpath的东西在某些浏览器中可能真的很贵，所以是的，我肯定会缓存它。
需要注意的事项：
- 没有ID的JQ参数的长系列
- 仅使用IE8或更低级别的类的选择器（添加标签名称，例如’div.someClass’）以获得显着改进 – IE8及以下版本必须在解释器级别上击中每一段HTML，而不是仅使用快速的本机方法使用该课程
- xpath风格的查询（许多较新的浏览器可能会处理这些问题）
在编写选择器时，请考虑必须查看多少标记才能获得它。 如果你知道你只想在某个ID中的特定类的div，那么执行其中一个$（’#ID div.someClass’）而不仅仅是$（’div.someClass’）;
但是，无论如何，仅仅根据工作规避的原则，如果您要使用两次或更多次，请缓存该值。 并尽可能多地重复请求来避免讨厌DOM。
通过ID查找元素非常快。 我不是100％确定我理解你的另一种方法，但我怀疑它会比它的id简单查找一个元素更好，浏览器知道如何最好地完成这项任务。 根据你的解释，我看不出你的方法会更快。