定义接收IEnumerable的方法：泛型类型约束还是基类？

这是个很务实的问题！先呼应下你提到的背景：.NET 4+里IEnumerable<T>作为协变接口（标记了out T），确实允许List<Derived>隐式转换为IEnumerable<Base>，这也是这两个选项能实现类似效果的核心原因。下面咱们拆解两者的差异——不只是风格，还有实际场景的影响：

Option B: void DoWork(IEnumerable<Base> objs); #

• 优势：极致简洁，可读性拉满。调用方不需要额外指定泛型参数，代码一眼就能看懂是处理Base类型的序列。如果你的方法只需要操作Base类定义的成员（比如调用Base的公共方法、访问公共属性），这个方案完全够用，没有多余的复杂度。
• 局限：完全丢失了具体的派生类型信息。如果后续方法内部需要用到Derived的特有成员，或者需要依赖具体类型做反射、实例化等操作，这个方案就无能为力了。

Option A: void DoWork<TBase>(IEnumerable<TBase> objs) where TBase : Base; #

• 优势：保留了具体的派生类型上下文。编译器会自动推断TBase为传入序列的实际类型（比如传入List<Derived>时，TBase就是Derived），这意味着：
  • 如果方法需要返回TBase类型的结果，或者要对序列做和具体类型相关的操作（比如用typeof(TBase)做反射逻辑、调用TBase专属的扩展方法），泛型版本能直接支持，不需要额外的类型转换。
  • 扩展性更强：以后需求变化时，只要不超出TBase : Base的约束，修改内部实现就能支持更多场景，不用改动方法签名。
• 劣势：定义上比Option B多了泛型约束的冗余感，对于只需要处理Base成员的简单场景，显得有点“重”。

怎么选？ #

• 如果你的方法只依赖Base类的公共成员，永远不需要知道具体的派生类型，选Option B——简洁、直观，减少不必要的泛型复杂度。
• 如果你的方法需要保留具体类型信息，或者未来可能有依赖具体类型的扩展需求，选Option A——它提供的类型安全性和扩展性是Option B无法替代的。

如果当前两种方案都能满足需求，那确实存在一定的风格差异，但泛型版本的潜在扩展性是不可忽视的细节。

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