返回类型选型探讨：ReadOnlyCollection<T>、List<T>、数组及IEnumerable<T>

作为天天跟集合接口打交道的开发者，我太懂这种纠结了——之前也专门研究过这个问题，刚好也看过主张优先用IReadOnlyCollection<T>的文章，结合实际项目经验，来聊聊我的看法：

先说说返回IEnumerable<T>的核心优势 #

• 极致的灵活性：它是.NET里最“抽象”的集合接口之一，作为方法编写者，你完全不用关心内部用的是数组、List、还是自定义的延迟枚举集合（比如LINQ查询的结果）。后续如果要修改内部实现，只要还是能枚举元素，调用方完全感知不到变化，兼容性拉满。
• 适配延迟执行场景：如果你的方法返回的是一个LINQ查询（比如Where/Select后的结果），返回IEnumerable<T>能天然保留延迟执行的特性，避免不必要的提前计算，这在处理大数据量或者数据库查询时特别有用。

但IEnumerable<T>的坑也真的不少（也是为什么会优先推荐IReadOnlyCollection<T>的原因） #

• 缺失关键信息，导致调用方低效操作：IEnumerable<T>没有暴露Count属性，调用方如果需要知道元素数量，要么只能手动遍历计数（如果背后是延迟枚举，这会触发一次完整遍历），要么就得先强制转换为ICollection<T>再获取Count——但这种转换不仅不优雅，还可能失败（不是所有IEnumerable<T>都实现了ICollection<T>）。我之前就踩过坑：调用方拿到IEnumerable<T>后直接用Count()扩展方法，结果背后是个数据库查询，导致重复执行了两次查询，性能直接崩了。
• 多次枚举的风险：如果返回的IEnumerable<T>是延迟执行的（比如LINQ查询、自定义的枚举器），调用方多次遍历会重复执行底层的逻辑（比如多次查数据库、多次计算）。而IReadOnlyCollection<T>明确表示这是一个已经“固化”的集合，调用方可以放心多次访问而不用担心额外开销。
• 语义不明确：IEnumerable<T>只承诺“可以枚举元素”，但调用方不知道这个集合是不是只读的、能不能被多次枚举、有没有固定的长度。而IReadOnlyCollection<T>的语义就清晰多了：这是一个只读的、有固定数量元素的集合，调用方可以基于这个语义做更合理的处理。

总结一下我的选择原则 #

• 如果你的方法确实需要延迟执行的特性（比如动态生成元素、数据库查询代理），那返回IEnumerable<T>没问题，但一定要在注释里明确说明“这个结果是延迟执行的，请勿多次枚举”。
• 如果方法返回的是已经计算好的、固定的元素集合，优先返回IReadOnlyCollection<T>——它比IEnumerable<T>提供了更清晰的语义和更高效的操作，同时又比IList<T>或者数组更轻量（不会暴露Add/Remove等修改方法，避免调用方误操作）。

内容的提问来源于stack exchange，提问作者Neo