标签：
1. const和readonly有什么区别？
2. 哪些类型可以定义为常量？常量const有什么风险？
3. 字段与属性有什么异同？
4. 静态成员和非静态成员的区别？
5. 自动属性有什么风险？
6. 特性是什么？如何使用？
7. 下面的代码输出什么结果？为什么？
List<Action> acs = new List<Action>(5);
for (int i = 0; i < 5; i++)
{
acs.Add(() => { Console.WriteLine(i); });
}
acs.ForEach(ac => ac());
8. C#中的委托是什么？事件是不是一种委托？
常量常量的基本概念就不细说了，关于常量的几个特点总结一下：
关于常量不支持跨程序集版本更新，举个简单的例子来说明：
public class A
{
public const int PORT = 10086;
public virtual void Print()
{
Console.WriteLine(A.PORT);
}
}
上面一段非常简单代码，其生产的IL代码如下，在使用常量变量的地方，把她的值拷过来了（把常量的值内联到使用的地方），与常量变量A.PORT没有关系了。假如A引用了B程序集（B.dll文件）中的一个常量，如果后面单独修改B程序集中的常量值，只是重新编译了B，而没有编译程序集A，就会出问题了，就是上面所说的不支持跨程序集版本更新。常量值更新后，所有使用该常量的代码都必须重新编译，这是我们在使用常量时必须要注意的一个问题。
补充一下枚举的本质接着上面的const说，其实枚举enum也有类似的问题，其根源和const一样，看看代码你就明白了。下面的是一个简单的枚举定义，她的IL代码定义和const定义是一样一样的啊！枚举的成员定义和常量定义一样，因此枚举其实本质上就相当是一个常量集合。
public enum EnumType : int
{
None=0,
Int=1,
String=2,
}
关于字段字段本身没什么好说的，这里说一个字段的内联初始化问题吧，可能容易被忽视的一个小问题（不过好像也没什么影响），先看看一个简单的例子：
public class SomeType
{
private int Age = 0;
private DateTime StartTime = DateTime.Now;
private string Name = "三体";
}
定义字段并初始化值，是一种很常见的代码编写习惯。但注意了，看看IL代码结构，一行代码（定义字段+赋值）被拆成了两块，最终的赋值都在构造函数里执行的。
那么问题来了，如果有多个构造函数，就像下面这样，有多半个构造函数，会造成在两个构造函数.ctor中重复产生对字段赋值的IL代码，这就造成了不必要的代码膨胀。这个其实也很好解决，在非默认构造函数后加一个“:this()”就OK了，或者显示的在构造函数里初始化字段。
public class SomeType
{
private DateTime StartTime = DateTime.Now;
public SomeType() { }
public SomeType(string name)
{
}
}
属性的本质属性是面向对象编程的基本概念，提供了对私有字段的访问封装，在C#中以get和set访问器方法实现对可读可写属性的操作，提供了安全和灵活的数据访问封装。我们看看属性的本质，主要手段还是IL代码：
public class SomeType
{
public int Index { get; set; }
public SomeType() { }
}
上面定义的属性Index被分成了三个部分：
因此可以说属性的本质还是方法，使用面向对象的思想把字段封装了一下。在定义属性时，我们可以自定义一个私有字段，也可以使用自动属性“{ get; set; } ”的简化语法形式。
使用自动属性时需要注意一点的是，私有字段是由编译器自动命名的，是不受开发人员控制的。正因为这个问题，曾经在项目开发中遇到一个因此而产生的Bug：
这个Bug是关于序列化的，有一个类，定义很多个（自动）属性，这个类的信息需要持久化到本地文件，当时使用了.NET自带的二进制序列化组件。后来因为一个需求变更，把其中一个字段修改了一下，需要把自动属性改为自己命名的私有字段的属性，就像下面实例这样。测试序列化到本地没有问题，反序列化也没问题，但最终bug还是被测试出来了，问题在与反序列化以前（修改代码之前）的本地文件时，Index属性的值丢失了！！！
private int _Index; public int Index { get { return _Index; } set { _Index = value; } }
因为属性的本质是方法+字段，真正的值是存储在字段上的，字段的名称变了，反序列化以前的文件时找不到对应字段了，导致值的丢失！这也就是使用自动属性可能存在的风险。
什么是委托？简单来说，委托类似于 C或 C++中的函数指针，允许将方法作为参数进行传递。
委托的本质——是一个类.NET中没有函数指针，方法也不可能传递，委托之所可以像一个普通引用类型一样传递，那是因为她本质上就是一个类。下面代码是一个非常简单的自定义委托：
public delegate void ShowMessageHandler(string mes);
看看她生产的IL代码
我们一行定义一个委托的代码，编译器自动生成了一堆代码：
因此，也就不难猜测，当我们调用委托的时候，其实就是调用委托对象的Invoke方法，可以验证一下，下面的调用代码会被编译为对委托对象的Invoke方法调用：
private ShowMessageHandler ShowMessage;
//调用
this.ShowMessage("123");
.NET的闭包闭包提供了一种类似脚本语言函数式编程的便捷、可以共享数据，但也存在一些隐患。
题目列表中的第7题，就是一个.NET的闭包的问题。
List<Action> acs = new List<Action>(5);
for (int i = 0; i < 5; i++)
{
acs.Add(() => { Console.WriteLine(i); });
}
acs.ForEach(ac => ac()); // 输出了 5 5 5 5 5，全是5？这一定不是你想要的吧！这是为什么呢？
上面的代码中的Action就是.NET为我们定义好的一个无参数无返回值的委托，从上一节我们知道委托实质是一个类，理解这一点是解决本题的关键。在这个地方委托方法共享使用了一个局部变量i，那生成的类会是什么样的呢？看看IL代码：
共享的局部变量被提升为委托类的一个字段了：
那该如何修正呢？很简单，委托方法使用一个临时局部变量就OK了，不共享数据：
List<Action> acss = new List<Action>(5);
for (int i = 0; i < 5; i++)
{
int m = i;
acss.Add(() => { Console.WriteLine(m); });
}
acss.ForEach(ac => ac()); // 输出了 0 1 2 3 4
至于原理，可以自己探索了！
const关键字用来声明编译时常量，readonly用来声明运行时常量。都可以标识一个常量，主要有以下区别：
1、初始化位置不同。const必须在声明的同时赋值；readonly即可以在声明处赋值，也可以在构造方法里赋值。
2、修饰对象不同。const即可以修饰类的字段，也可以修饰局部变量；readonly只能修饰类的字段 。
3、const是编译时常量，在编译时确定该值，且值在编译时被内联到代码中；readonly是运行时常量，在运行时确定该值。
4、const默认是静态的；而readonly如果设置成静态需要显示声明 。
5、支持的类型时不同，const只能修饰基元类型或值为null的其他引用类型；readonly可以是任何类型。
基元类型或值为null的其他引用类型，常量的风险就是不支持跨程序集版本更新，常量值更新后，所有使用该常量的代码都必须重新编译。
因为自动属性的私有字段是由编译器命名的，后期不宜随意修改，比如在序列化中会导致字段值丢失。
特性与属性是完全不相同的两个概念，只是在名称上比较相近。Attribute特性就是关联了一个目标对象的一段配置信息，本质上是一个类，其为目标元素提供关联附加信息，这段附加信息存储在dll内的元数据，它本身没什么意义。运行期以反射的方式来获取附加信息。使用方法可以参考：http://www.cnblogs.com/anding/p/5129178.html
List<Action> acs = new List<Action>(5);
for (int i = 0; i < 5; i++)
{
acs.Add(() => { Console.WriteLine(i); });
}
acs.ForEach(ac => ac());
输出了 5 5 5 5 5，全是5！因为闭包中的共享变量i会被提升为委托对象的公共字段，生命周期延长了
什么是委托？简单来说，委托类似于 C或 C++中的函数指针，允许将方法作为参数进行传递。
事件可以理解为一种特殊的委托，事件内部是基于委托来实现的。
版权所有，文章来源：http://www.cnblogs.com/anding
个人能力有限，本文内容仅供学习、探讨，欢迎指正、交流。
标签：
原文地址：http://www.cnblogs.com/zhangxiaolei521/p/5258895.html
