在我通常遇到的情况下，我很少直接使用IList。

通常我只是把它用作方法的参数

void ProcessArrayData(IList almostAnyTypeOfArray)
{
    // Do some stuff with the IList array
}

这将允许我对. net框架中的几乎任何数组进行泛型处理，除非它使用IEnumerable而不是IList，这种情况有时会发生。

这实际上取决于你需要什么样的功能。我建议在大多数情况下使用List类。当你需要创建一个自定义数组，其中可能包含一些非常特定的规则，你希望将这些规则封装在一个集合中，这样你就不会重复自己的操作，但仍然希望. net将其识别为一个列表时，IList是最好的选择。

我有两条原则:

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

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

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

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

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

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

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

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

你通常最好使用最通用的可用类型，在这种情况下是IList，甚至更好的是IEnumerable接口，这样你可以在以后方便地切换实现。

然而，在。net 2.0中，有一个恼人的事情——IList没有Sort()方法。您可以使用提供的适配器:

ArrayList.Adapter(list).Sort()

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

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