<p>相等的对象必须返回相同的哈希码，哈希码相等不保证对象相等；重写 GetHashCode() 时必须同步重写 Equals()，且二者逻辑一致，仅基于不可变的关键字段计算，推荐使用 HashCode.Combine 或 hash * 31 + field?.GetHashCode() ?? 0。</p>
重写 GetHashCode() 的核心原则是：**相等的对象必须返回相同的哈希码；哈希码相等不意味着对象一定相等（允许哈希冲突，但应尽量减少）**。这是 .NET 中字典（Dictionary<K,V>）、哈希集（HashSet<T>）等哈希结构正确工作的基础。
必须同时重写 Equals() 和 GetHashCode()
如果只重写 GetHashCode() 而不重写 Equals()，或反之，会导致逻辑不一致：两个 Equals() 返回 true 的对象可能因哈希码不同被散列到不同桶中，从而在字典中查不到；反之，若仅重写 Equals() 而哈希码始终为默认（如引用哈希），则所有实例可能被塞进同一个桶，严重退化性能。
- 重写
Equals(object)时，也应重写Equals(T)（实现IEquatable<T>）以提升性能 -
GetHashCode()的实现必须与Equals()的逻辑严格一致——即决定“相等性”的字段，也必须参与哈希码计算 - 若类是可变的（字段后续可能修改），且该类实例会用作字典键或加入
HashSet，则不应重写GetHashCode()（或确保关键字段不可变）
哈希码应基于不可变、参与相等判断的关键字段
哈希码应由那些真正定义对象“身份”的字段组合计算得出，且这些字段在对象生命周期内不应改变（否则哈希码变化将导致字典中丢失条目）。例如，一个表示二维坐标的 Point 类，X 和 Y 是决定相等性的唯一字段，也是哈希计算的唯一输入。
- 避免使用
DateTime.Now、随机数、数据库 ID（未加载时为 0）、或任何可能变化的属性 - 推荐使用
HashCode.Combine(field1, field2, ...)（.NET Core 2.1+），它能高效、均匀地混合多个值 - 手动实现时，常用公式：
hash = hash * 31 + field?.GetHashCode() ?? 0（注意空值处理和乘数选择）
避免常见错误：空引用、浮点数、集合类型直接哈希
直接对可能为 null 的引用类型调用 .GetHashCode() 会抛出异常；float/double 的 NaN 或精度问题会导致相等对象哈希不一致；对数组、列表等集合类型直接调用 GetHashCode() 通常返回引用哈希，而非内容哈希，违背相等性契约。
- 字符串、数值类型可直接用
.GetHashCode()；引用类型建议用空合并：name?.GetHashCode() ?? 0 - 浮点字段建议先转为
int/long表示（如BitConverter.ToInt32(BitConverter.GetBytes(value))），再参与计算 - 集合字段（如
IList<int>）需遍历元素逐个哈希并组合，或使用Enumerable.SequenceEqual配合自定义哈希逻辑（注意性能）
测试你的实现是否合理
编写简单单元测试验证两条基本规则：
- 相同对象多次调用
GetHashCode()应返回相同值（稳定性） - 两个
Equals()为true的实例，其GetHashCode()必须相等 - 可额外检查哈希分布（如生成大量实例，观察哈希码模小质数后的余数分布是否相对均匀）
基本上就这些。不复杂但容易忽略细节，尤其在涉及可变状态或嵌套对象时。守住“相等 ⇒ 哈希相等”这一底线，就能让字典和哈希表稳稳工作。
