可变类型实现IEquatable<T>时是否应重写GetHashCode？

嘿，这个问题确实是C#里关于相等性和哈希码的经典坑，我来给你理清楚！

官方对GetHashCode的约束其实是这几条：

• 两个逻辑相等的对象，必须返回相同的哈希码（只要它们处于相等状态时）
• 哈希码不需要全局唯一，但要尽量分散，避免哈希冲突
• 最关键的一条：如果对象被用作哈希集合（比如Dictionary、HashSet）的键或元素，那么在它处于集合中的整个生命周期里，哈希码绝对不能变！因为哈希集合是靠哈希码定位元素的，一旦哈希码变了，集合就再也找不到这个对象了。

1. 类的实例不会被放入哈希集合 #

这种场景下，哈希码的“稳定性”要求没那么严格。如果你用所有参与相等性判断的属性来计算哈希码，当属性变更时哈希码跟着变是完全可以接受的——毕竟你不会用它当字典键或者存HashSet里，也就不会有定位失效的问题。很多教程里的例子其实都是针对这种场景的。

2. 类的实例可能被放入哈希集合 #

这时候必须保证哈希码的稳定性，有两种常见实现方式：

• 用构造时就确定的不变字段（比如唯一ID）来计算哈希码，哪怕其他可变属性修改，哈希码也不会变
• 严格约束：一旦对象被放入哈希集合，就不允许修改任何参与哈希码计算的属性

举个代码例子：

public class User : IEquatable<User>
{
    // 构造时赋值，永远不变的唯一标识
    public Guid Id { get; }
    // 可变的业务属性
    public string Nickname { get; set; }

    public User(Guid id) => Id = id;

    public bool Equals(User other)
    {
        if (other is null) return false;
        // 相等性基于不变的Id
        return Id.Equals(other.Id);
    }

    public override bool Equals(object obj) => Equals(obj as User);

    public override int GetHashCode()
    {
        // 用不变的Id计算哈希码，确保稳定性
        return Id.GetHashCode();
    }
}

那些提到“对象变更时哈希码可以变”的资源，默认场景是不把对象用作哈希集合的键/元素；而强调“GetHashCode不能变”的资源，是针对对象会被放入哈希集合的场景——这两种场景的要求本来就不一样，所以看起来像是冲突。

• 如果你不确定类的实例会不会被放进哈希集合，优先按“哈希码稳定”的方式实现，比如用构造时确定的不变字段计算哈希码，避免后续踩坑
• 如果明确不会用在哈希集合里，用参与相等性判断的所有属性计算哈希码是可以的，但建议在类的注释里说明：该类不适合用作哈希集合的键
• 永远不要在对象已经被放入哈希集合后，修改任何参与哈希码计算的属性——哪怕你用了可变的哈希码实现，这都会导致集合无法正确找到该对象，出现诡异的BUG

内容的提问来源于stack exchange，提问作者Neo