我不认为这类事情有严格的规则，但我通常会遵循使用尽可能轻松的方式的指导方针，直到绝对必要的时候。

例如，假设您有一个Person类和一个Group类。Group实例有很多人，所以这里使用List是有意义的。当我在Group中声明列表对象时，我将使用IList<Person>并将其实例化为list。

public class Group {
  private IList<Person> people;

  public Group() {
    this.people = new List<Person>();
  }
}

而且，如果你甚至不需要IList中的所有东西，你也可以使用IEnumerable。对于现代的编译器和处理器，我不认为它们真的有任何速度上的差异，所以这只是风格的问题。

我同意李的建议，接受一些参数，但不要回头。

如果你指定你的方法来返回一个接口，这意味着你以后可以自由地更改确切的实现，而消费方法永远不会知道。我认为我永远不需要从List<T>更改，但后来不得不更改为使用自定义列表库，以获得它提供的额外功能。因为我只返回了一个IList<T>，所以使用这个库的人都不需要改变他们的代码。

当然，这只需要应用于外部可见的方法(即公共方法)。我个人甚至在内部代码中使用接口，但如果你做了破坏性的更改，你可以自己更改所有的代码，这并不是严格必要的。

我有两条原则:

接受最基本的工作类型 返回用户需要的最丰富的类型

因此，当编写一个接受集合的函数或方法时，不要让它接受List，而是让它接受IList<T>、ICollection<T>或IEnumerable<T>。泛型接口即使对于异构列表也仍然有效，因为System。Object也可以是T。如果您决定在以后使用Stack或其他数据结构，这样做将为您省去麻烦。如果在函数中所需要做的只是逐个遍历它，那么IEnumerable<T>才是真正需要的。

另一方面，当从函数返回一个对象时，您希望为用户提供尽可能丰富的操作集，而不需要他们进行强制转换。在这种情况下，如果内部是List<T>，返回一个List<T>的副本。

使用最低基类型总是最好的。这使接口的实现者或方法的使用者有机会在幕后使用他们喜欢的任何东西。

对于集合，应该尽可能使用IEnumerable。这提供了最大的灵活性，但并不总是适合。

你应该只在你需要它的时候使用这个接口，例如，如果你的列表被强制转换为一个IList实现而不是list。这是真的，例如，当你使用NHibernate，它在检索数据时将列表转换为NHibernate包对象。

如果List是您将用于某个集合的唯一实现，则可以将其声明为具体的List实现。

一个List对象允许你创建一个列表，添加东西到它，删除它，更新它，索引到它等等。当你只想要一个泛型列表时，List就会被使用，你可以在其中指定对象类型。

另一方面，IList是一个接口。基本上，如果您想创建自己的自定义列表，比如一个名为BookList的列表类，那么您可以使用接口为您的新类提供基本方法和结构。IList用于当你想创建自己的特殊子类来实现List时。

另一个区别是: IList是一个接口，不能被实例化。List是一个类，可以实例化。它的意思是:

IList<string> list1 = new IList<string>(); // this is wrong, and won't compile

IList<string> list2 = new List<string>();  // this will compile
List<string> list3 = new List<string>();   // this will compile