.NET中各种相等

方式	类别	类默认行为	原生类型	结构	不同类型可否相等	行为是否能覆写	应用场景
Object.Equals	静态方法	调用Equals实例方法	值相等	各字段值相等	可	可	参数可能为Null的情况
Object.ReferenceEquals	静态方法	引用相等	返回False	返回False	不可	不可	测试
==	操作符	引用相等	值相等	须定义后使用	不可	可	原生类型，简单业务逻辑
Equals	实例方法	引用相等	值和类型相等	各字段值相等	可	可	一般处理

对于值类型，实现==操作像一个点缀，而如果想实现相等比较操作，应该优先重写Equals方法（同样若要实现大小比较，应该优先实现 IComparable接口，而不是实现比较操作符），从Object继承的Equals方法用于值类型时，比较两个对象的所有字段，全相等才为 True。要注意它据说用了反射，效率很低的。但是它低归低，为什么一定要优先重写它？

　　因为所有.Net Framework键值集合，都是用Equals实例方法做比较的，所以它实际上成了.Net中的法定天平，无论是原生类型、结构或类的实例，都应以 Equals方法作为其标准的相等比较方式，包括我们自己实现的类型。用实例方法的好处也可以理解，更灵活，我们可以添加一些重载的Equals方法，申 明不同的比较前提条件。与重写的默认Equals方法配合，构成一套完整的比较规则，以符合现实里复杂多变的标准。

　　重写Equals方法时，官方推荐重写GetHashCode方法，要是你不用此类型作键值集合键的话，其实无所谓。

　　个别情况中，复杂到重载Equals方法也力不从心时，我们就要定义专门用来比较相等的功能类。.Net Framework已经提供了一个接口System.Collections.IEqualityComparer，并有几个内置的实现，如 StringComparer、EqualityComparer，我们自己写的比较类也不妨实现这个接口，当然，只要能用也不必计较那么多。看.Net Framework源代码，能发现好多个乱七八糟的类用于比较相等，大概是内部特权吧。

截取部分  全文链接：http://www.cnblogs.com/XmNotes/archive/2011/06/23/2088341.html