List中Count与Capacity差异的原因及消除方法问询

先搞懂两个属性的本质 #

首先得明确Count和Capacity的核心区别：

• Count：代表List当前实际存储的元素数量，你这里的1559就是真实的元素个数，完全符合预期。
• Capacity：是List底层依赖的数组当前能容纳的最大元素数。List会自动维护这个值，每次元素数量超过当前Capacity时，它会自动扩容（通常是翻倍），避免频繁重新分配内存——这是.NET为了提升性能做的优化。

为什么你的代码会出现差异？ #

你用的Enumerable.Repeat(0, max).ToList()，问题出在ToList()的内部逻辑上：
Enumerable.Repeat()返回的是一个迭代器（RepeatIterator），它并没有实现ICollection<T>接口，所以ToList()在创建List时，无法提前知道这个迭代器到底有多少元素。它只能从默认容量开始，一边迭代添加元素，一边触发扩容逻辑。当最终添加完1559个元素时，最后一次扩容后的Capacity刚好是2048（因为扩容是翻倍式的，比如从1024扩容到2048，足够容纳1559个元素），就出现了Capacity大于Count的情况。

如何消除二者的差异？ #

如果你确实需要让Capacity和Count保持一致（比如要节省内存），有两种常用方法：

方法1：提前指定List的初始容量

在创建List的时候直接传入元素总数，让它一次性分配足够的内存，避免后续扩容：

List<int> array = new List<int>(max);
array.AddRange(Enumerable.Repeat(0, max));

这样List一开始就会把Capacity设为max，添加元素时不会触发扩容，最终Count和Capacity都会等于max。

方法2：调用TrimExcess()方法

如果已经创建好了List，可以调用TrimExcess()来让Capacity匹配当前的Count：

List<int> array = Enumerable.Repeat(0, max).ToList();
array.TrimExcess();

⚠️ 注意：.NET有个小逻辑——如果Count已经超过Capacity的90%，TrimExcess()会直接跳过，因为此时扩容的空间利用率已经很高了，调整容量反而得不偿失。你的情况1559/2048≈76%，所以这个方法完全有效。

最后补充一句 #

其实这种差异本身不是“问题”，是List的性能优化策略。如果你的List后续还要添加元素，保留多余的Capacity反而能避免再次扩容的开销。只有当你确定不会再添加元素、且在意内存占用时，才需要调整二者的差异。

内容的提问来源于stack exchange，提问作者Reza Hatami