为什么需要EqualityComparer
在C#中判断两个对象是否相等，看似简单，实际上背后涉及一整套机制。当把对象放进Dictionary、HashSet这类基于哈希的集合时，框架并不会直接使用你直觉中的相等规则，而是通过一个叫做相等比较器的组件来完成判断。这个组件的核心抽象就是IEqualityComparer<T>接口和它配套的抽象类EqualityComparer<T>。
很多初学者遇到过这样的坑：往HashSet里添加两个内容完全一样的对象，结果集合里出现了两条记录。原因就是自定义类默认继承自object的Equals方法，它比较的是引用地址而不是内容。只要对象是两次new出来的，哪怕每个属性都相同，引用也不一样，于是就被判定为不相等。
EqualityComparer<T>.Default是框架提供的默认比较器，它会按照以下顺序决定使用什么逻辑：首先检查类型是否实现了IEquatable<T>接口，如果实现了就调用强类型的Equals，避免装箱带来性能损耗；否则回退到object.Equals，也就是引用比较。理解这个机制，有助于我们明白为什么推荐的做让自定义类型直接实现IEquatable<T>，而不是仅仅重写Equals方法。
实现IEqualityComparer接口自定义比较逻辑
当比较规则不属于类型本身的语义，而是某个特定场景的需求时，就不应该改动类型本身，而是提供一个独立的比较器。典型例子是字符串比较：有的场景需要忽略大小写，有的需要忽略首尾空格。这时候实现IEqualityComparer<T>接口就是最合适的方案。
这个接口要求实现两个方法：Equals和GetHashCode。两个方法必须逻辑一致，这是硬性要求。哈希集合的工作原理是先用哈希码分组，再在组内用Equals精确判断。如果两个对象Equals返回true但哈希码不同，它们会被分到不同的桶里，Equals根本没有机会被调用，查找和去重就会失效。这是使用自定义比较器时最容易犯的错误。
下面是一个忽略大小写的字符串比较器的完整实现：
public class CaseInsensitiveComparer : IEqualityComparer<string>
{
public bool Equals(string x, string y)
{
if (ReferenceEquals(x, y)) return true;
if (x is null || y is null) return false;
return x.Equals(y, StringComparison.OrdinalIgnoreCase);
}
public int GetHashCode(string obj)
{
if (obj is null) return 0;
// 统一转大写后再计算哈希，保证与Equals逻辑一致
return obj.ToUpperInvariant().GetHashCode();
}
}使用方式很直接，在构造集合时把比较器传进去即可：
var set = new HashSet<string>(new CaseInsensitiveComparer());
set.Add("Hello");
set.Add("HELLO"); // 不会被重复添加
var dict = new Dictionary<string, int>(new CaseInsensitiveComparer());
dict["Name"] = 1;
Console.WriteLine(dict["name"]); // 输出 1值得一提的是，字符串场景下优先考虑框架自带的StringComparer.OrdinalIgnoreCase，它经过高度优化，比自己写的版本更可靠。自定义比较器更适合用在你自己的业务类型上。
针对自定义类的多字段比较与泛型封装
假设有一个表示用户的类，业务要求用户名和邮箱都相同的两个对象视为同一个人。此时可以写一个针对该类的专用比较器：
public class User
{
public string UserName { get; set; }
public string Email { get; set; }
public int Age { get; set; }
}
public class UserComparer : IEqualityComparer<User>
{
public bool Equals(User x, User y)
{
if (ReferenceEquals(x, y)) return true;
if (x is null || y is null) return false;
return x.UserName == y.UserName
&& string.Equals(x.Email, y.Email, StringComparison.OrdinalIgnoreCase);
}
public int GetHashCode(User obj)
{
// 用参与相等判断的字段计算哈希，Age不参与就不该进入哈希计算
unchecked
{
int hash = 17;
hash = hash * 31 + (obj.UserName?.GetHashCode() ?? 0);
hash = hash * 31 + (obj.Email?.ToUpperInvariant().GetHashCode() ?? 0);
return hash;
}
}
}注意哈希码计算中使用了unchecked块防止乘法溢出抛异常，并且用31这个质数做乘数让哈希分布更均匀。凡是参与Equals判断的字段都必须参与GetHashCode计算，而没参与判断的字段（如这里的Age）绝不能混入，否则逻辑就对不上了。
如果项目中有很多类似的按字段比较需求，每个类型都写一个比较器类会非常啰嗦。可以封装一个泛型比较器，通过委托传入比较逻辑：
public class DelegateComparer<T> : IEqualityComparer<T>
{
private readonly Func<T, T, bool> _equals;
private readonly Func<T, int> _getHashCode;
public DelegateComparer(Func<T, T, bool> equals, Func<T, int> getHashCode)
{
_equals = equals;
_getHashCode = getHashCode;
}
public bool Equals(T x, T y) => _equals(x, y);
public int GetHashCode(T obj) => _getHashCode(obj);
}
// 使用示例
var comparer = new DelegateComparer<User>(
(a, b) => a?.UserName == b?.UserName,
u => u?.UserName?.GetHashCode() ?? 0);这种方式适合一次性、场景化的比较需求。不过要注意委托调用的性能开销比直接实现接口略高，在超高频调用场景下还是推荐老老实实写比较器类。另外，LINQ中的Distinct、GroupBy、Contains等操作都有带比较器参数的重载，把自定义比较器传进去就能改变这些操作的行为，非常灵活。
继承EqualityComparer抽象类与常见陷阱
除了接口，.NET还提供了EqualityComparer<T>抽象类。继承它比实现接口多一个好处：你的比较器会自动成为该类型的默认比较器。也就是说，在泛型方法内部通过EqualityComparer<T>.Default取比较器时，取到的就是你定义的版本，调用方不需要显式传递。实现方式也很简单：
public class Product : EqualityComparer<Product>
{
public string Code { get; set; }
public override bool Equals(Product x, Product y)
{
if (ReferenceEquals(x, y)) return true;
if (x is null || y is null) return false;
return x.Code == y.Code;
}
public override int GetHashCode(Product obj)
{
return obj?.Code?.GetHashCode() ?? 0;
}
}实际使用中有几个容易踩的坑需要特别留意。第一是可变性陷阱：如果对象作为字典的键之后又修改了参与哈希计算的字段，它的哈希码就变了，但它在字典里仍留在旧桶的位置，之后再也查不到这个键了。所以参与相等判断的字段最好设计成只读。第二是哈希碰撞处理：不同的对象可以有相同的哈希码，这是允许的，Equals会在同桶内做二次判断，只是碰撞多了会影响性能。第三是null处理：Dictionary本身不允许null键，但某些自定义用法中比较器要能正确处理null入参，建议在两个方法开头都做判空。
还有一个容易被忽略的点：从.NET Core开始，可以用元组或ValueTuple轻松组合多个字段做比较，配合记录类型record的自动值相等语义，很多场景已经不需要手写比较器了。但在.NET Framework老项目或者需要复杂自定义规则的场景下，掌握EqualityComparer的原理和用法依然是必备技能。总结一下核心原则：Equals和GetHashCode必须逻辑一致、参与判断的字段保持不变性、能用框架内置比较器就不重复造轮子。把这些原则记牢，相等性判断相关的坑基本都能避开。
C#EqualityComparer自定义比较器修改时间：2026-09-12 07:35:12