视情况而定。如果确切的答案真的很重要，那就做一些分析，找出答案。如果你确定你永远不会有超过一定数量的元素在集合中，使用List。如果数字是无界的，则使用HashSet。

这取决于很多因素……列表实现，CPU架构，JVM，循环语义，equals方法的复杂性，等等…当列表变得足够大，可以有效地进行基准测试(1000多个元素)时，基于哈希的二进制查找就可以轻松地击败线性搜索，并且差异只会在此基础上扩大。

希望这能有所帮助!

盈亏平衡将取决于计算散列的成本。哈希计算可以是微不足道的，或者不是…:-)总有System.Collections.Specialized.HybridDictionary类帮助你不必担心盈亏平衡点。

使用HashSet<>还是List<>取决于您需要如何访问您的集合。如果你需要保证项目的顺序，使用一个列表。如果没有，请使用HashSet。让微软去担心他们的哈希算法和对象的实现吧。

HashSet将访问项目而不必枚举集合(复杂度为O(1)或接近它)，并且由于List保证顺序，与HashSet不同，一些项目将必须被枚举(复杂度为O(n))。

这取决于你在哈希什么。如果你的键是整数，在HashSet更快之前，你可能不需要很多项。如果你在一个字符串上输入键，那么它会更慢，这取决于输入的字符串。

你肯定可以很容易地建立一个基准吗?

答案一如既往地是“视情况而定”。我假设从标签你说的是c#。

你最好的办法就是决定

一组数据 使用要求

并编写一些测试用例。

它还取决于您如何对列表进行排序(如果它已经排序)，需要进行哪种比较，“Compare”操作对列表中的特定对象需要多长时间，甚至取决于您打算如何使用集合。

一般来说，最好的选择不是基于您正在处理的数据的大小，而是基于您打算如何访问它。您是否拥有与特定字符串或其他数据相关联的每个数据片段?基于哈希的集合可能是最好的。存储数据的顺序重要吗?还是需要同时访问所有数据?那么，一个常规的清单可能会更好。

附加:

Of course, my above comments assume 'performance' means data access. Something else to consider: what are you looking for when you say "performance"? Is performance individual value look up? Is it management of large (10000, 100000 or more) value sets? Is it the performance of filling the data structure with data? Removing data? Accessing individual bits of data? Replacing values? Iterating over the values? Memory usage? Data copying speed? For example, If you access data by a string value, but your main performance requirement is minimal memory usage, you might have conflicting design issues.