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

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>.

数组Vs.列表是典型的可维护性Vs.性能问题。几乎所有开发人员都遵循的经验法则是，您应该兼顾两者，但当两者发生冲突时，请选择可维护性而不是性能。该规则的例外情况是当性能已经被证明是一个问题时。如果你把这个原则应用到数组Vs.列表中，你会得到这样的结果:

使用强类型列表，直到遇到性能问题。如果遇到性能问题，请决定是否使用数组对解决方案的性能更有利，而不是在维护方面对解决方案造成损害。

请记住，使用List是不可能做到这一点的:

List<string> arr = new List<string>();

arr.Add("string a");
arr.Add("string b");
arr.Add("string c");
arr.Add("string d");

arr[10] = "new string";

它生成一个异常。

相反，使用数组:

string[] strArr = new string[20];

strArr[0] = "string a";
strArr[1] = "string b";
strArr[2] = "string c";
strArr[3] = "string d";

strArr[10] = "new string";

但是对于数组，不会自动调整数据结构的大小。您必须手动或使用Array管理它。调整方法。

一个技巧是用一个空数组初始化List。

List<string> arr = new List<string>(new string[100]);

arr[10] = "new string";

但在这种情况下，如果你使用Add方法添加一个新元素，它将被注入到列表的末尾。

List<string> arr = new List<string>(new string[100]);

arr[10] = "new string";

arr.Add("bla bla bla"); // this will be in the end of List

如果我确切地知道我需要多少元素，比如我需要5个元素，而且只需要5个元素，那么我就使用数组。否则我只使用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设置为只读确实有帮助，但会导致运行时错误，而不是编译时错误。