C#中直接用==或Equals无法比较自定义对象的逻辑相等性，因其默认仅判断引用相等；需通过重写Equals/GetHashCode或实现IEqualityComparer来按字段值比较，且二者必须保持一致性。
为什么直接用 == 或 Equals 无法比较自定义对象
C# 中的引用类型默认继承自 Object，其 Equals 方法只做引用相等判断（即两个变量是否指向同一内存地址）。即使两个 Person 对象字段值完全相同，a.Equals(b) 仍返回 false——除非你重写 Equals 和 GetHashCode。但重写会侵入类型本身，而 IEqualityComparer 提供了更灵活、可复用、不污染业务类的方案。
常见错误现象包括：Dictionary 插入重复键却不报错、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
{
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;
}
public int GetHashCode(Person obj)
{
return obj?.Id.GetHashCode() ?? 0;
}}
在 LINQ 和集合中传入自定义比较器的实际用法
不同场景下传参方式略有差异，关键看 API 是否接受 IEqualityComparer 重载：
-
Distinct()：直接传实例，如 people.Distinct(new PersonIdComparer())
-
Dictionary 构造时传入：new Dictionary(new PersonIdComparer())
-
GroupBy() 不直接支持比较器，需改用 GroupBy(x => x.Id) 或配合 IEquatable 实现
-
Contains()、Except()、Intersect() 等都提供带比较器的重载，务必显式传入，否则走默认引用比较
注意：Lambda 无法直接构造 IEqualityComparer，不要试图写 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{ 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; } public int GetHashCode(Person obj) { return obj?.Id.GetHashCode() ?? 0; }}
在 LINQ 和集合中传入自定义比较器的实际用法
不同场景下传参方式略有差异，关键看 API 是否接受
IEqualityComparer重载：
Distinct()：直接传实例，如people.Distinct(new PersonIdComparer())Dictionary构造时传入：new Dictionary(new PersonIdComparer()) GroupBy()不直接支持比较器，需改用GroupBy(x => x.Id)或配合IEquatable实现Contains()、Except()、Intersect()等都提供带比较器的重载，务必显式传入，否则走默认引用比较注意：Lambda 无法直接构造
IEqualityComparer，不要试图写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返回值变了，整个字典就查不到东西了。
