这里有个很有意思的题目，先别运行程序，猜猜它会输出什么？

public class A<T>
{
　　public class B : A<int>
　　{
　　　　public void M()
　　　　{
　　　　　　Console.WriteLine(typeof(T).ToString());
　　　　}
　　　　public class C : B { }
　　}
}
class Program
{
　　static void Main(string[] args)
　　{
　　　　A<string>.B.C c = new A<string>.B.C();
　　　　c.M();
　　}
}

　　这里的T是int、string还是其它的什么？还是程序压根儿就不能通过编译？

　　...

　　...

　　...

　　答案是System.Int32，你猜对了吗？很可能这跟你的期望值并不一致。我们来看看它背后的玄妙之处。

　　有人认为c.M方法输出Int32，因为B的声明B : A<int>告诉B，T将一直是int。这好像是有道理的，却不是真正的原因。我们先不管C，执行这一行代码(new A<string>.B()).M()，它会输出：String。B是A<int>的子类并不意味着B中的T总是int。

　　问题的根本在于声明class C : B会产生不明确的内容：即是class C : A<T>.B 还是class C : A<int>.B？我们得首先搞清楚这个问题。

　　先看继承和嵌套类的区别：

public class X
{
　　public void M() { }
}
public class Y
{
　　public void N() { }
　　public class Z : X { }
}
...

　　(new Y.Z()).M(); // 合法，M是继承自基类的方法

　　(new Y.Z()).N(); // 不合法，外部类的成员不是内部类的方法

　　在我们的测试题中，我们调用了A<string>.B.C类的方法M，它本质上则调用了基类的M方法。如果基类是A<T>.B，那么应调用A<T>.B.M，即输出T的当前值：String；如果基类是A<int>.B，那么应调用A<int>.B.M，即总是输出：Int32。

　　而程序的结果告诉我们C#选择了后者。是不是有些不可思议？

　　也许程序中的泛型扰乱我们的直觉。那就看一个不使用泛型的例子：

public class D
{
　　public class E { }
}
public class F
{
　　public class E { }
　　public class G
　　{
　　　　public E e; // 很明显这里是 F.E
　　}
}
public class H : D
{
　　public E e; // 很明显这里是 D.E
}

　　OK，目前为止，一切都是合法的，而且也没什么异议。当我们通过类型名称来引用类型时，类型可以来自于基类（H.e），也可以来自于外部类（G.e）。但是如果这两种情况同时出现会如何呢？

public class J
{
　　public class E { }
　　public class K : D
　　{
　　　　public E e; // 是J.E 还是D.E?
　　}
}

　　这种情况是合法的吗？答案是肯定的。此时C#认为基类要优先于外部类。这也合乎常理，派生类与基类的关系是“is-a”，内部类与外部类的关系是“包含于”，前者要比后者更为紧密。

　　还可以这么理解：从基类继承下来的成员都属于“当前的作用域”，因此从“外部的作用域”获得的成员的优先级要低一些。

　　一般地，对于一个类型S，在其上下文中对一个名称进行解析的算法是：

　　S的类型参数（type parameter）

　　S可以访问的内部类

　　S的基类中可以访问的内部类（访问基类的顺序是由近及远）

　　S的外部类

　　现在回到开始的问题。我们看看在解析C的基类的时候发生了什么。我们调用的是B.M()，所以问题可以转化为找到正确的B。首先C没有类型参数，也没有内部类。

　　A<T>.B的基类是A<int>，而外部类则是A<T>，两者都有一个名称为B的内部类。选哪一个呢？根据上面的算法，基类优先，即A<int>.B。

　　这个过程实在是非常的绕，虽然跟着文章得出了结论，还是有些模糊。。。