它们可能不受欢迎，但我是游戏项目中的数组的粉丝。 -迭代速度在某些情况下是很重要的，如果你对每个元素不做太多操作，数组上的foreach的开销就会大大减少 -添加和删除helper函数并不难 -速度比较慢，但如果你只建了一次，那就无所谓了 -在大多数情况下，更少的额外内存被浪费(只有数组结构才真正重要) -稍微少一点垃圾和指针和指针追逐

话虽如此，在实践中，我使用列表的次数远多于数组，但它们都有各自的位置。

如果List是内置类型，那么他们就可以优化包装器和枚举开销。

填充列表比填充数组更容易。对于数组，您需要知道数据的确切长度，但对于列表，数据大小可以是任何大小。你可以把一个列表转换成一个数组。

List<URLDTO> urls = new List<URLDTO>();

urls.Add(new URLDTO() {
    key = "wiki",
    url = "https://...",
});

urls.Add(new URLDTO()
{
    key = "url",
    url = "http://...",
});

urls.Add(new URLDTO()
{
    key = "dir",
    url = "https://...",
});

// convert a list into an array: URLDTO[]
return urls.ToArray();

Another situation not yet mentioned is when one will have a large number of items, each of which consists of a fixed bunch of related-but-independent variables stuck together (e.g. the coordinates of a point, or the vertices of a 3d triangle). An array of exposed-field structures will allow the its elements to be efficiently modified "in place"--something which is not possible with any other collection type. Because an array of structures holds its elements consecutively in RAM, sequential accesses to array elements can be very fast. In situations where code will need to make many sequential passes through an array, an array of structures may outperform an array or other collection of class object references by a factor of 2:1; further, the ability to update elements in place may allow an array of structures to outperform any other kind of collection of structures.

Although arrays are not resizable, it is not difficult to have code store an array reference along with the number of elements that are in use, and replace the array with a larger one as required. Alternatively, one could easily write code for a type which behaved much like a List<T> but exposed its backing store, thus allowing one to say either MyPoints.Add(nextPoint); or MyPoints.Items[23].X += 5;. Note that the latter would not necessarily throw an exception if code tried to access beyond the end of the list, but usage would otherwise be conceptually quite similar to List<T>.

当集合本身的不可变性是客户端和提供者代码之间契约的一部分时(不一定是集合中项目的不可变性)以及当IEnumerable不合适时，应该优先使用数组而不是List。

例如,

var str = "This is a string";
var strChars = str.ToCharArray();  // returns array

很明显，对"strChars"的修改不会改变原始的"str"对象，无论实现级是否了解"str"的底层类型。

但是假设

var str = "This is a string";
var strChars = str.ToCharList();  // returns List<char>
strChars.Insert(0, 'X');

在这种情况下，仅仅从代码片段中还不清楚insert方法是否会改变原始的“str”对象。它需要String的实现级知识来做出判断，这打破了契约式设计方法。在String的情况下，这不是一个大问题，但在几乎所有其他情况下，这可能是一个大问题。将List设置为只读确实有帮助，但会导致运行时错误，而不是编译时错误。

因为没有人提到:在c#中，数组是一个列表。MyClass[]和List<MyClass>都实现了IList<MyClass>。(例如void Foo(IList<int> Foo)可以像Foo(new[]{1,2,3})或Foo(new List<int>{1,2,3})一样调用)

因此，如果你正在编写一个接受List<MyClass>作为参数的方法，但只使用功能的子集，你可能想声明为IList<MyClass>，以方便调用者。

细节:

为什么数组实现IList? 如何在c#数组部分实现IList<T>?

Lists in .NET are wrappers over arrays, and use an array internally. The time complexity of operations on lists is the same as would be with arrays, however there is a little more overhead with all the added functionality / ease of use of lists (such as automatic resizing and the methods that come with the list class). Pretty much, I would recommend using lists in all cases unless there is a compelling reason not to do so, such as if you need to write extremely optimized code, or are working with other code that is built around arrays.