答案 0 :(得分：5)
GetHashCode()的合同要求它，但由于任何人都可以自己实施，因此无法保证。
许多类（尤其是哈希表）需要它才能正常运行。
如果要实现一个类，则应始终确保两个相等的对象具有相同的哈希码。
如果您正在实现一个实用程序方法/类，您可以假设两个相等的对象具有相同的哈希码（如果没有，则是另一个类，而不是您的，这是错误的）。
如果您正在实施具有安全隐患的内容，则无法假设它。
答案 1 :(得分：2)
如果这是真的，K和M总是有相同的HashCode？
是
或者更确切地说应该。散列码的消费者（例如，容器）可以假设相等的对象具有相等的散列码，或者更确切地说，不相等的散列码意味着对象是不相等的。 （不等的对象可以具有相同的哈希码：有更多可能的对象而不是哈希码，因此必须允许这样做。）
或者这取决于编程语言？
没有
答案 2 :(得分：1)
Yes, it should return the same hash code.
我会说它与语言无关。但是没有保证好像其他程序已经正确实现了这一点。
GetHashCode根据当前实例返回一个值 适用于散列算法和数据结构，如散列 表。必须返回两个相同类型且相同的对象 相同的哈希码，以确保实例 System.Collections.HashTable和 System.Collections.Generic.Dictionary正常工作。
答案 3 :(得分：1)
如果这是真的，K和M总是有相同的HashCode？
是。除非他们有一个邪恶的被覆盖的Equals方法。但那会被认为是破碎的。
但请注意，反之则不然，
如果K和M具有相同的HashCode，它仍然可以是K.Equals(M) == false
答案 4 :(得分：0)
这取决于对象的Equals实现。它可能会在引擎盖下使用GetHashCode，但它也没有。所以基本上如果你有一个带有自定义Equals实现的对象，那么两个对象的HashCode可能会有所不同。
答案 5 :(得分：0)
在您的应用程序中，哈希码必须唯一地标识对象的实例。这是.net平台的一部分，因此，无论您正在创作哪种.net语言，哈希码值都应该有效。
答案 6 :(得分：0)
GetHashCode()可以为不同的对象返回相同的哈希值。如果Equals()返回相同的值，则应使用GetHashCode(),来比较非GetHashCode()的对象 - Equals()的实现应考虑另一个对象相等性检查。
哈希数据结构能够通过使用冲突解决算法来处理这种情况。
来自wikipedia：
当随机散列时，哈希冲突几乎是不可避免的 一大组可能键的子集。例如，如果有2,500个键 即使是完全均匀的随机，也可以钻进一百万桶 分配，根据生日问题有95％的几率 至少有两个密钥被散列到同一个插槽。
因此，大多数哈希表实现都有一些冲突 处理此类事件的解决方案策略。一些常见的策略是 如下面所描述的。所有这些方法都需要键（或指针） 他们）与相关的值一起存储在表中。