如何生成不受元素顺序影响的.NET集合哈希码？

需要实现一种能配合IReadOnlySet<T>.SetEquals使用的哈希码逻辑，.NET自带的HashCode类型对元素顺序敏感，无法满足需求——打乱集合元素顺序后，生成的哈希码会完全不同，示例代码如下：

var random = new Random();
var items = random.GetItems(Enumerable.Range(0, 100).ToArray(), 100);

for (var i = 0; i < 10; i++)
{
    if (i > 0)
    {
        random.Shuffle(items);
    }

    var combined = new HashCode();

    foreach (var item in items)
    {
        combined.Add(item);
    }

    Console.WriteLine("Hash code is {0}", combined.ToHashCode());
}

运行结果：

Hash code is -1745381383
Hash code is 206620979
Hash code is 1544865526
Hash code is 877430619
Hash code is 1668984788
Hash code is 54187377
Hash code is -758239719
Hash code is 1005287804
Hash code is 614467421
Hash code is -954645367

请问如何生成不受元素顺序影响的相同哈希码？

方法1：加法结合质数乘法（推荐） #

利用加法的交换律，结合质数乘法降低哈希碰撞概率，这是.NET生态中常用的无顺序哈希实现，性能和稳定性表现均衡。

public static int GetUnorderedHashCode<T>(IReadOnlySet<T> set)
{
    if (set == null) return 0;
    int hash = 17; // 初始种子值，避免空集合与单元素0的哈希冲突
    foreach (var item in set)
    {
        int itemHash = item?.GetHashCode() ?? 0;
        hash = hash * 31 + itemHash; // 31是常用质数，特性可减少碰撞概率
    }
    return hash;
}

方法2：排序后使用HashCode累加 #

如果集合元素实现了IComparable<T>，可先对元素排序，再用HashCode累加。排序后无论原集合顺序如何，输入到HashCode的序列一致，最终哈希码也相同。

public static int GetSortedUnorderedHashCode<T>(IReadOnlySet<T> set) where T : IComparable<T>
{
    if (set == null) return 0;
    var sortedItems = set.OrderBy(x => x).ToArray();
    var hash = new HashCode();
    foreach (var item in sortedItems)
    {
        hash.Add(item);
    }
    return hash.ToHashCode();
}

方法3：异或运算（不推荐） #

异或运算满足交换律，但存在明显缺陷：若元素哈希码重复（即使集合无重复元素，哈希码仍可能冲突），异或会抵消相同值的哈希，导致不同集合产生相同哈希码的概率极高，仅适合对碰撞容忍度极高的场景。

public static int GetXorUnorderedHashCode<T>(IReadOnlySet<T> set)
{
    if (set == null) return 0;
    int hash = 0;
    foreach (var item in set)
    {
        int itemHash = item?.GetHashCode() ?? 0;
        hash ^= itemHash;
    }
    return hash;
}

选型建议 #

• 优先选择方法1，无需元素支持排序，性能开销低，碰撞概率可控。
• 方法2适合必须依赖HashCode类型的场景，但排序会带来额外性能开销，元素数量大时需谨慎使用。
• 方法3仅作为备选，不推荐用于业务逻辑中的哈希计算。

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