我知道已经有很多关于 GetHashCode 的讨论，但是他们通常提供的建议对于解决应该是一个相对简单的问题并不是很有帮助......
我有一个简单的 DTO 类，其中包含许多自动实现的各种类型的属性，我想对此类的两个实例执行简单的基于值的比较。（主要目的是确定在不同时间点生成的实例之间发生的任何变化。）
这可以通过添加适当的方法很容易地完成。但碰巧的是，这正是 Equals() 方法和 IEquatable 接口的用途。所以我认为，与其仅仅实现一个非标准的自定义方法，不如实现 IEquatable...
现在问题来了：MSDN 文档说为了实现 IEquatable，您还应该覆盖 Object.Equals()。这是有道理的。但是如果你覆盖 Object.Equals() 你也应该覆盖 HetHashCode()。仍然不是一个真正的问题，我在这里找到了关于如何计算它的各种讨论，如果你决定的话。
然而，我读过的文档和所有讨论都说 GetHashCode() 输出应该保持稳定，因此不建议在可变对象上覆盖它......我可以理解这一点。（不过，让我注意，我无意将此类用作字典键，这似乎是主要问题...）
但是，我拥有的 DTO 类是可变的。使其不可变将需要使用笨拙的构造函数或带有大量参数或构建器模式的静态工厂方法，并且会阻止您使用相当方便的对象初始值设定项语法。总而言之，这真的不值得付出努力和带来不便。
所以现在怎么办？我仍然想添加一种比较内容的方法，但现在我不太确定推荐的最佳实践是什么。
编辑：
忘了补充，我还看到了基于您班级中的一组不可变字段实现 GetHashCode 的建议。但是，由于我的所有属性都是自动实现和可设置的，因此从技术上讲，它们都可以更改...
更新：
感谢您的回答。所以基本上我不需要太担心 GetHashCode，只要“我知道我在做什么”——这意味着该类不会在键控集合中使用。
也感谢关于 IEqualityComparer 的建议，我可能会试一试。
选择“接受”的答案有点困难，因为它们都是很好的答案，但我必须选择一个......
有人可能会认为您的 DTO 根本不应该有任何行为，包括Equals或GetHashCode。如果您想比较这些类型的对象，请使用您在其他地方定义的方法。这就很好地解决了问题。
但假设您对 DTO 不那么严格，那么您必须重写Equals(Object). 您不一定必须实施IEquatable，但如果您愿意，也可以实施。而且，是的，如果您重写Equals(Object)，那么您确实应该重写GetHashCode。
GetHashCode是的，依赖可变字段通常不是一个好主意。但如果您不会使用键控集合中的对象，则不必担心。继续做你需要做的事。请记住：MSDN 中的指南就是指南。如果您了解规则并了解违反规则的风险，并且您愿意承担后果，那么就去做吧。