定义泛型类/接口时是否应定义非泛型基类/接口？

这种写法既不是单纯的社区习惯，也不是无意义的八股要求，是实际功能需求、官方设计规范、历史兼容三者共同作用的结果：

• 首先是解决泛型本身的特性限制：泛型的闭合构造类型是相互独立的，比如IFoo<int>和IFoo<string>在运行时是完全不同的类型，在C# 4.0引入泛型协变/逆变之前，两者没有任何类型兼容关系，就算有协变，对于逆变、或者值类型作为泛型参数的场景，你也没法把它们统一转成某个泛型父类型。这时候如果有非泛型的IFoo基接口，你就可以把不同泛型参数的实例放到同一个集合、用同一套逻辑处理，不用全转成object丢失类型安全。另外在反射、动态代理、序列化这类编译期无法确定泛型参数的场景，非泛型基类型提供了不需要猜测T类型就能访问公共成员的入口，比如你不需要知道一个List<T>里存的是什么类型，就能通过非泛型ICollection的Count属性拿到元素总数。
• 其次这是.NET官方框架设计指南的明确要求：所有对外暴露的公共泛型类型，如果存在不依赖泛型参数就能实现的成员，就必须配套定义非泛型基类型。你看到的所有CLR内置泛型类型全是按这个规范实现的：Task<T>继承自Task，List<T>实现了非泛型IList，IEnumerable<out T>继承自非泛型IEnumerable，全是规范落地的结果，不是开发者随便写的。
• 最后是历史兼容原因：.NET 2.0才正式引入泛型，在这之前框架里的集合、异步相关类型全是非泛型实现，后续推出泛型版本时配套对应非泛型基类/接口，可以保证老版本代码不需要重写就能和新泛型类型交互，避免版本升级出现API断裂。

这不是所有泛型类型都必须遵守的铁则，要不要做完全看实际场景：

• 推荐配套非泛型基类型的场景：
  • 泛型类型是公共API的一部分，会被外部模块或者第三方代码调用
  • 类型上确实存在和泛型参数无关的公共成员，比如Id属性、Count属性、Dispose方法、状态判断方法等
  • 存在聚合不同泛型参数实例、通过反射/动态逻辑处理类型的需求
• 完全不需要画蛇添足的场景：
  • 泛型类型是程序集内部的私有/内部类型，不会对外暴露
  • 类型的所有成员都强依赖泛型参数，抽不出任何可以放到非泛型基类里的公共逻辑，硬写非泛型版本只会把成员参数换成object，平白增加装箱拆箱开销、丢掉泛型的类型安全优势
  • 所有使用该类型的代码都能在编译期明确泛型参数类型，不存在统一操作不同泛型实例的需求

别为了“和CLR内置代码写法一致”就硬套这个模式，很多内部业务代码里给所有泛型接口塞一个空的非泛型父接口，除了增加维护成本没有任何实际价值，属于典型的过度设计。

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