为什么直接用 == 或 Equals 无法比较自定义对象
C# 中的引用类型默认继承自
Object，其
Equals方法只做引用相等判断（即两个变量是否指向同一内存地址）。即使两个
Person对象字段值完全相同，
a.Equals(b)仍返回
false——除非你重写
Equals和
GetHashCode。但重写会侵入类型本身，而
IEqualityComparer<t></t>提供了更灵活、可复用、不污染业务类的方案。
常见错误现象包括：
Dictionary<person string></person>插入重复键却不报错、
Distinct()去重失效、
Contains()返回
false即使逻辑上“应该存在”。
实现 IEqualityComparer 的最小必要步骤要让集合类（如
Dictionary
、HashSet
、LINQ 的 Distinct
）按你的规则比较对象，必须同时满足两个条件：
实现 Equals(T x, T y)
：定义“什么算相等”，返回 true
当且仅当逻辑上应视为同一项
实现 GetHashCode(T obj)
：确保 Equals(x, y) == true
时，GetHashCode(x) == GetHashCode(y)
；否则哈希容器（如 Dictionary
）会直接跳过比较，导致行为异常
示例：为
Person
类按 Id
判断相等：public class PersonIdComparer : IEqualityComparer<Person>
{
public bool Equals(Person x, Person y)
{
if (x is null && y is null) return true;
if (x is null || y is null) return false;
return x.Id == y.Id;
}
<pre class="brush:php;toolbar:false;">public int GetHashCode(Person obj)
{
return obj?.Id.GetHashCode() ?? 0;
}}
在 LINQ 和集合中传入自定义比较器的实际用法
不同场景下传参方式略有差异，关键看 API 是否接受
IEqualityComparer<t></t>
重载：
Distinct()
：直接传实例，如 people.Distinct(new PersonIdComparer())
Dictionary<tkey tvalue></tkey>
构造时传入：new Dictionary<person string>(new PersonIdComparer())</person>
GroupBy()
不直接支持比较器，需改用 GroupBy(x => x.Id)
或配合 IEquatable<t></t>
实现
Contains()
、Except()
、Intersect()
等都提供带比较器的重载，务必显式传入，否则走默认引用比较
注意：Lambda 无法直接构造
IEqualityComparer<t></t>
，不要试图写 x => x.Id
来替代——这是键选择器，不是比较逻辑。
容易被忽略的 GetHashCode 性能与一致性陷阱
很多人只关注
Equals
正确性，却忽略 GetHashCode
的一致性要求：只要用于比较的字段（如 Id
）不变，多次调用 GetHashCode
必须返回相同值；且一旦对象被加入哈希集合（如 HashSet
），就不该再修改这些字段——否则哈希桶位置错乱，后续查找失败。
避免在 GetHashCode
中调用复杂计算或访问可能变化的属性（如 DateTime.Now
、ToString()
）
若比较依据是多个字段（如 FirstName + LastName
），用 HashCode.Combine(f1, f2)
（.NET Core 2.1+）或 (f1?.GetHashCode() ?? 0) * 397 ^ (f2?.GetHashCode() ?? 0)
手动组合，别简单相加（易冲突）
如果 T
是可变对象，且业务上允许修改比较字段，那就别用哈希集合，改用 List
+ FindIndex
等线性查找
真正难的不是写完这两个方法，而是想清楚：这个“相等”语义是否稳定、是否跨上下文一致、是否会被缓存机制依赖。一不留神，
GetHashCode
返回值变了，整个字典就查不到东西了。
要让集合类（如
Dictionary、
HashSet、LINQ 的
Distinct）按你的规则比较对象，必须同时满足两个条件： 实现
Equals(T x, T y)：定义“什么算相等”，返回
true当且仅当逻辑上应视为同一项 实现
GetHashCode(T obj)：确保
Equals(x, y) == true时，
GetHashCode(x) == GetHashCode(y)；否则哈希容器（如
Dictionary）会直接跳过比较，导致行为异常
示例：为
Person类按
Id判断相等：
public class PersonIdComparer : IEqualityComparer<Person>
{
public bool Equals(Person x, Person y)
{
if (x is null && y is null) return true;
if (x is null || y is null) return false;
return x.Id == y.Id;
}
<pre class="brush:php;toolbar:false;">public int GetHashCode(Person obj)
{
return obj?.Id.GetHashCode() ?? 0;
}}
在 LINQ 和集合中传入自定义比较器的实际用法
不同场景下传参方式略有差异，关键看 API 是否接受
IEqualityComparer<t></t>重载：
Distinct()：直接传实例，如
people.Distinct(new PersonIdComparer())
Dictionary<tkey tvalue></tkey>构造时传入：
new Dictionary<person string>(new PersonIdComparer())</person>
GroupBy()不直接支持比较器，需改用
GroupBy(x => x.Id)或配合
IEquatable<t></t>实现
Contains()、
Except()、
Intersect()等都提供带比较器的重载，务必显式传入，否则走默认引用比较
注意：Lambda 无法直接构造
IEqualityComparer<t></t>，不要试图写
x => x.Id来替代——这是键选择器，不是比较逻辑。
容易被忽略的 GetHashCode 性能与一致性陷阱
很多人只关注
Equals正确性，却忽略
GetHashCode的一致性要求：只要用于比较的字段（如
Id）不变，多次调用
GetHashCode必须返回相同值；且一旦对象被加入哈希集合（如
HashSet），就不该再修改这些字段——否则哈希桶位置错乱，后续查找失败。 避免在
GetHashCode中调用复杂计算或访问可能变化的属性（如
DateTime.Now、
ToString()） 若比较依据是多个字段（如
FirstName + LastName），用
HashCode.Combine(f1, f2)（.NET Core 2.1+）或
(f1?.GetHashCode() ?? 0) * 397 ^ (f2?.GetHashCode() ?? 0)手动组合，别简单相加（易冲突） 如果
T是可变对象，且业务上允许修改比较字段，那就别用哈希集合，改用
List+
FindIndex等线性查找
真正难的不是写完这两个方法，而是想清楚：这个“相等”语义是否稳定、是否跨上下文一致、是否会被缓存机制依赖。一不留神，
GetHashCode返回值变了，整个字典就查不到东西了。
