为何IDictionary<TKey, TValue>同时实现ICollection与IEnumerable？是否冗余？

首先明确说：这不属于冗余实现，而是.NET框架设计时的刻意选择，背后有几个关键原因：

1. 显式声明提升可读性 #

虽然ICollection<KeyValuePair<TKey, TValue>>已经继承了IEnumerable<KeyValuePair<TKey, TValue>>和IEnumerable，但把这些接口显式写在IDictionary<TKey, TValue>的定义里，能让开发者一眼就看懂这个接口支持的所有核心能力——不用再层层去翻父接口的继承链，直接就能知道它既是一个可枚举的集合，也是一个键值对的集合。这种“显性化”的设计，对于理解接口的功能边界非常友好。

2. 编译器层面的传递性继承 #

从技术角度说，接口的继承是传递性的：如果A继承B，B继承C，那么A自动继承C。所以即使IDictionary<TKey, TValue>只写继承ICollection<...>，它依然会间接拥有IEnumerable<...>和IEnumerable的成员。但显式列出这些接口，并不会导致任何编译问题，只是让代码文档更清晰。

接下来聊聊你提到的第二个问题：为什么IEnumerable要继承IEnumerable？

这完全是为了兼容性和API的一致性：

• 非泛型的IEnumerable是.NET 1.0时代就存在的核心接口，当时还没有泛型。等到.NET 2.0引入泛型后，为了让旧代码能无缝使用新的泛型集合，设计IEnumerable<T>时让它继承了非泛型的IEnumerable。这样，任何泛型集合都可以直接在依赖非泛型枚举的场景（比如早期的foreach循环、旧的绑定控件）中使用，不用额外做类型转换。
• 这种继承关系也保持了集合框架的层次连贯性：所有支持枚举的类型，不管是泛型还是非泛型，都共享同一个根接口，让整个集合体系的设计更统一。

至于ICollection<T>的设计，它继承IEnumerable<T>也是顺理成章的——集合的核心能力之一就是能被枚举，通过继承IEnumerable<T>，它自动获得了泛型枚举的能力，同时通过IEnumerable<T>间接继承IEnumerable，也兼容了非泛型场景的需求。

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