令人惊讶的是，这些List和IList的问题(或答案)都没有提到签名差异。(这就是为什么我在SO上搜索这个问题!)

下面是List中包含的在IList中找不到的方法，至少在。net 4.5(大约2015年)

AddRange AsReadOnly BinarySearch 能力 ConvertAll 存在 找到 FindAll FindIndex FindLast FindLastIndex ForEach GetRange InsertRange LastIndexOf RemoveAll RemoveRange 反向 排序 ToArray TrimExcess TrueForAll

因为定义IList或ICollection将为接口的其他实现打开空间。

您可能希望有一个IOrderRepository，它在IList或ICollection中定义一个订单集合。然后，您可以使用不同类型的实现来提供订单列表，只要它们符合IList或ICollection定义的“规则”。

You can look at this argument from several angles including the one of a purely OO approach which says to program against an Interface not an implementation. With this thought, using IList follows the same principal as passing around and using Interfaces that you define from scratch. I also believe in the scalability and flexibility factors provided by an Interface in general. If a class implmenting IList<T> needs to be extended or changed, the consuming code does not have to change; it knows what the IList Interface contract adheres to. However using a concrete implementation and List<T> on a class that changes, could cause the calling code to need to be changed as well. This is because a class adhering to IList<T> guarantees a certain behavior that is not guaranteed by a concrete type using List<T>.

此外，还可以在类上修改List<T>的默认实现，例如为.Add、.Remove或任何其他IList方法实现IList<T>，为开发人员提供了很大的灵活性和能力，否则由List<T>预定义

接口是一种承诺(或契约)。

承诺总是这样，越小越好。

IList<T>是一个接口，所以你可以继承另一个类，仍然实现IList<T>，而继承List<T>阻止你这样做。

例如，如果有一个类a，你的类B继承了它，那么你不能使用List<T>

class A : B, IList<T> { ... }

有人说“总是使用IList<T>而不是List<T>”。 他们想让你把你的方法签名从void Foo(List<T> input)改成void Foo(IList<T> input)。

这些人错了。

事实比这更微妙。如果返回一个IList<T>作为库的公共接口的一部分，则为将来创建自定义列表留下了一些有趣的选项。你可能永远不需要这个选项，但它是一个参数。我认为这是返回接口而不是具体类型的全部理由。值得一提的是，在这种情况下，它有一个严重的缺陷。

作为一个小小的反驳，您可能会发现每个调用者都需要一个List<T>，并且调用代码中充斥着.ToList()

但更重要的是，如果你接受一个IList作为参数，你最好小心，因为IList<T>和List<T>的行为不一样。尽管名称相似，尽管共享接口，但它们并不公开相同的契约。

假设你有这样的方法:

public Foo(List<int> a)
{
    a.Add(someNumber);
}

一位乐于助人的同事“重构”该方法以接受IList<int>。

你的代码现在坏了，因为int[]实现了IList<int>，但是是固定的大小。ICollection<T> (IList<T>的基础)的契约要求在尝试从集合中添加或删除项之前使用它检查IsReadOnly标志的代码。List<T>的契约没有。

利斯科夫替换原则(简化)指出派生类型应该能够用来代替基类型，没有额外的先决条件或后置条件。

这似乎打破了利斯科夫替换原则。

 int[] array = new[] {1, 2, 3};
 IList<int> ilist = array;

 ilist.Add(4); // throws System.NotSupportedException
 ilist.Insert(0, 0); // throws System.NotSupportedException
 ilist.Remove(3); // throws System.NotSupportedException
 ilist.RemoveAt(0); // throws System.NotSupportedException

但事实并非如此。答案是这个例子使用了IList<T>/ICollection<T>错误。如果你使用ICollection<T>，你需要检查IsReadOnly标志。

if (!ilist.IsReadOnly)
{
   ilist.Add(4);
   ilist.Insert(0, 0); 
   ilist.Remove(3);
   ilist.RemoveAt(0);
}
else
{
   // what were you planning to do if you were given a read only list anyway?
}

如果有人传递给你一个数组或列表，如果你每次都检查标志并有一个回退，你的代码将正常工作…但真的;谁会这么做?你事先不知道你的方法是否需要一个可以接受额外成员的列表吗?难道你没有在方法签名中指定吗?如果你被传递一个像int[]这样的只读列表，你到底要做什么?

您可以将List<T>替换为正确使用IList<T>/ICollection<T>的代码。您不能保证可以将IList<T>/ICollection<T>替换为使用List<T>的代码。

在使用抽象而不是具体类型的许多参数中，使用单一责任原则/接口隔离原则(依赖于尽可能窄的接口)是有吸引力的。在大多数情况下，如果您正在使用List<T>，并且您认为可以使用更窄的接口，为什么不使用IEnumerable<T>呢?如果你不需要添加项目，这通常是一个更好的选择。如果需要添加到集合，请使用具体类型List<T>。

对我来说，IList<T>(和ICollection<T>)是。net框架中最糟糕的部分。IsReadOnly违反最小意外原则。从不允许添加、插入或删除项的类(如Array)不应该实现具有添加、插入和删除方法的接口。(参见https://softwareengineering.stackexchange.com/questions/306105/implementing-an-interface-when-you-dont-need-one-of-the-properties)

IList<T>是否适合您的组织?如果有同事要求您将方法签名改为使用IList<T>而不是List<T>，请询问他们如何将元素添加到IList<T>中。如果他们不知道IsReadOnly(大多数人都不知道)，那么就不要使用IList<T>。永远。

注意IsReadOnly标志来自ICollection<T>，表示是否可以从集合中添加或删除项;但它并没有指出它们是否可以被替换，这在数组(返回isreadonly == true)的情况下是可以的。

有关IsReadOnly的更多信息，请参见msdn definition of ICollection<T>。IsReadOnly