下面的示例是理解为什么不允许这样做的最简单方法：
abstract class Fruit{}class Apple : Fruit{}class Banana : Fruit{}// This should intuitively compile right? Cause an Apple is Fruit.List<Fruit> fruits = new List<Apple>();// But what if I do this? Adding a Banana to a list of Applesfruits.Add(new Banana());最后一条语句将破坏.NET的类型安全性。
但是，数组允许这样做：
Fruit[] fruits = new Apple[10]; // This is perfectly fine
然而，把一个
Banana进入
fruits还是会破坏类型安全，所以为此.NET必须做对每一个阵列插入类型检查，并抛出一个异常，如果它不是真正的
Apple。这可能对性能造成很小的影响，但是可以通过
struct围绕这两种类型创建包装器来规避，因为对于值类型不会执行此检查（因为它们不能从任何东西继承）。刚开始，我不明白为什么要做出这个决定，但是您会经常遇到为什么这样做很有用。最常见的是
String.Format，它可以接受
paramsobject[]任何数组。
但是，在.NET 4中，有一个类型为safe covariance /
contravariance的安全协方差/协方差，您可以进行这样的分配，但前提是必须证明它们是安全的。有什么可证明的安全性？
IEnumerable<Fruit> fruits = new List<Apple>();
以上在.NET 4中起作用，因为
IEnumerable<T>成为了
IEnumerable<out T>。在
out该手段
T只能永远都 出来
的
fruits，并且有 没有一种方法在所有 上
IEnumerable<outT>有史以来采用
T的参数，这样你就可以永远正确传递
Banana到
IEnumerable<Fruit>。
矛盾几乎是相同的，但我总是忘记它的确切细节。毫不奇怪，为此，现在
in在类型参数上使用了关键字。
