如果您计划构建一个公共API，最好使用IEnumerable而不是List，因为您应该使用最简化的接口/类。如果需要，List允许您通过索引访问对象。

这是一个关于何时使用IEnumerable、ICollection、List等的很好的指南。

IEnumerable的作用是提供一种表示一组泛型对象的方式。它是.NET框架中的一个接口，可以用于枚举（遍历）集合中的元素。

IEnumerable的使用的原因是为了提供一种通用的方式来处理集合中的元素。它允许您对集合进行迭代，而无需关心集合的底层实现细节。这使得代码更具灵活性和可扩展性。

另一方面，List是一个具体的集合类，它实现了IEnumerable接口。它提供了许多有用的方法和属性，例如添加、删除、排序等。但是，使用List作为公共API的返回类型可能会限制调用方的灵活性，因为它暴露了更多的实现细节。

因此，如果您希望提供一个更通用的API，可以考虑使用IEnumerable作为返回类型。这样，调用方可以使用适当的迭代方式来处理返回的集合，而不需要依赖于特定的集合实现。这样，您的API将更具灵活性和可扩展性，可以适应不同的使用场景。

总之，使用IEnumerable作为公共API的返回类型是一种良好的实践，它提供了更大的灵活性和可扩展性。通过使用最小化的接口/类，您可以减少对具体实现的依赖，并提供一种通用的方式来处理集合中的元素。这将使您的API更易于使用和理解，并为调用方提供更大的自由度。

IEnumerable接口的作用是作为方法的参数类型，它可以接收任何实现了该接口的对象，比如数组、List和字符串等。这样使用IEnumerable作为参数类型的方法就具有了更高的灵活性，可以在更广泛的场景中使用。

相反地，如果使用具体的类型作为参数类型，比如List，那么该方法只能接收List类型的对象，不能接收数组或者字符串等其他类型的对象。

当然，如果一个方法确实需要一个列表作为参数（而不是任意的可枚举对象），那么应该使用更强的类型，比如IList。但是仍然应该避免使用具体的类型，比如List，而是使用接口类型，这样可以允许传递数组和其他实现了该接口的对象。

在方法的返回类型方面，通常最好使用最强的类型（尽量不要限制特定的类型）。例如，对于一个返回集合的方法，可以使用IEnumerable作为返回类型，而不是具体的类型，这样可以使方法更加通用。

需要注意的是，数组只部分实现了IList接口，因此使用该接口时需要谨慎。对于数组来说，如果将一个Cat[]数组赋值给一个IList类型的变量，并且将一个非空的Animal对象赋值给该数组的第一个元素，那么这个操作会成功。但是如果将一个非Cat类型的对象赋值给该数组的第一个元素，那么这个操作将会失败。

有人提出了使用协变数组的想法，即通过定义一个IArray接口来实现，然后让IList接口继承自该接口。但是这种做法也存在一些问题，因为协变数组只能在不支持泛型的语言中使用。

总之，IEnumerable接口的作用是提供了一种更灵活、通用的方法参数类型，可以接收任意实现了该接口的对象。这样可以使方法更加灵活，并且可以在更广泛的场景中使用。同时，在方法的返回类型方面，应该尽量使用最强的类型，以增加方法的通用性。

IEnumerable的作用是告诉我们可以枚举T类型的一系列实例。如果您需要允许某人查看并对集合中的每个对象执行某些操作，那么这就足够了。

另一方面，List是IEnumerable的具体实现，它以一种特定且已知的方式存储对象。在内部，这可能是存储通过IEnumerable公开的值的非常好的方式，但是并不总是适用于List。例如，如果您不需要通过索引访问项目，而是不断在集合的开头插入项目，然后从末尾删除项目，那么使用Queue会更合适。

通过在API中使用IEnumerable，您可以在任何时候更改内部实现，而无需更改任何其他代码。这对于使代码具有灵活性和可维护性有巨大的好处。

我非常支持您关于与实现解耦的观点，但我也认为清楚地说明预期的使用方式是有意义的。即使我有一个List，将其称为IEnumerable也清楚地表明我在该用法中期望从集合中获得的功能是可枚举性功能，而不是List的任何其他功能。这实际上是意图的文档化使用方式；我发现这些明确的意图文档化通常提供了您所指出的解耦效果。

我同意，不过在这种情况下，我建议使用IList而不是IEnumerable。

好观点，尽管这带出了一个完全不同的问题，即“接口与具体实例”，我认为这是一个不同的问题。