问IEquatable和仅仅覆盖Object.Equals()有什么区别？

EN

主要原因是性能。当泛型在.NET 2.0中引入时，他们能够添加一堆整洁的类，如List<T>、Dictionary<K,V>、HashSet<T>等。这些结构大量使用了GetHashCode和Equals。但是对于值类型，这需要装箱。IEquatable<T>允许结构实现强类型的Equals方法，因此不需要装箱。因此，在泛型集合中使用值类型时，性能要好得多。

引用类型受益不大，但IEquatable<T>实现确实让您避免了System.Object的强制转换，如果频繁调用，这可能会有所不同。

但是，正如在Jared Parson's blog中所指出的，您的必须仍然实现标准的Object.Equals和Object.GetHashcode覆盖。

根据MSDN的说法

如果实现IEquatable<T>，还应重写Object.Equals(Object)和GetHashCode的基类实现，以便它们的行为与IEquatable<T>.Equals方法的行为一致。如果确实重写了Object.Equals(Object)，则还会在调用类上的静态Equals(System.Object, System.Object)方法时调用重写的实现。这确保了Equals方法的所有调用都返回一致的结果。

因此，这两者之间似乎没有真正的函数差异，只是它们都可以根据类的使用方式来调用。从性能的角度来看，最好使用通用版本，因为没有与之相关的装箱/拆箱损失。

从逻辑的角度来看，实现接口也更好。重写对象并不能真正告诉任何人你的类实际上是可等同的。覆盖可能只是一个不做任何事情的类或一个浅层实现。显式地使用这个接口会说，“嘿，这个东西对于相等检查是有效的！”这只是更好的设计。

用一个实际的例子来扩展Josh所说的。+1 to Josh -我正要在我的答案中写同样的话。

public abstract class EntityBase : IEquatable<EntityBase>
{
    public EntityBase() { }

    #region IEquatable<EntityBase> Members

    public bool Equals(EntityBase other)
    {
        //Generic implementation of equality using reflection on derived class instance.
        return true;
    }

    public override bool Equals(object obj)
    {
        return this.Equals(obj as EntityBase);
    }

    #endregion
}

public class Author : EntityBase
{
    public Author() { }
}

public class Book : EntityBase
{
    public Book() { }
}

这样，我就有了可重用的Equals()方法，它可以为我所有的派生类开箱即用。