Linq Contains性能对比：List<int>与int[]的差异

嘿，这个问题问得相当务实——刚好我对.NET里这两种集合的底层实现和实际运行表现有不少实践经验，咱们把这点事儿说透：

先看底层实现逻辑 #

不管是int[]还是List<int>，它们的Contains方法本质上都是线性遍历+逐个值对比：

• 对于int[]，.NET的Array.Contains内部是调用Array.IndexOf，从数组第一个元素开始依次对比，找到匹配项就立刻返回，遍历终止于找到元素或数组末尾。
• 对于List<int>，它的Contains方法会调用自身的IndexOf，而List的底层本来就是封装了一个int[]（就是我们常说的内部缓冲区），所以IndexOf的逻辑和数组几乎完全一致：直接遍历内部数组，用Count属性（而不是数组的Length）来控制遍历边界，同样是找到匹配就返回。

实际性能差异：几乎可以忽略 #

既然两者都是对连续内存的线性扫描，而且都是处理值类型int（不需要拆装箱，对比操作是极快的整数直接比较），在小规模数据集+少量查询的场景下，你几乎不可能感知到性能差异：

• 哪怕极端点说，数组的遍历可能比List快个几纳秒每元素，在几百甚至几千个元素的情况下，总耗时差异也在微秒级别——这种差异别说业务代码里感受不到，就连用普通性能测试工具都很难测出稳定的差值。
• 唯一可能出现细微差别的场景？比如List的Count属性是个字段直接读取，数组的Length也是字段，两者都是O(1)操作，所以连这一步的开销都几乎一致。

关于HashSet的补充 #

你提到的“转换HashSet开销过大”完全正确：HashSet的构建需要为每个元素计算哈希值，还要处理哈希冲突（比如链表挂载），对于小数据集来说，这个构建的时间成本远超过几次线性查找的耗时，所以确实没必要为了Contains去转HashSet。

总结 #

如果你已经因为扩容需求把数组转成了List，那就放心用List<int>.Contains()就行——在你的场景下，它和数组的Contains性能没有显著差异，怎么方便怎么来就好。

内容的提问来源于stack exchange，提问作者Jack Miller