HashSet<Guid>与Tuple<Guid,Guid>作为Dictionary键对比：Guid顺序无关场景

结论：优先选择第一种方案，无论性能、可维护性还是未来扩展多Guid的需求，都明显优于第二种方案

两种方案对比 #

第一种方案（排序+Tuple/ValueTuple） #

优势：

• 性能开销极低：2个Guid排序成本可以忽略，就算未来扩展到3个Guid，排序3个元素的开销也远低于第二种方案的HashSet操作，而且不需要每次计算哈希/相等比较时都生成新对象，GC压力极小
• 代码简洁无冗余：不需要自定义类、自定义比较器，没有额外样板代码，可读性高
• 扩展成本极低：未来要加入第三个Guid作为键的组成部分，只需要把排序后的3个Guid放到ValueTuple中即可，不需要修改其他逻辑，改动量极小
• 稳定性高：直接使用.NET框架内置的Tuple/ValueTuple比较逻辑，没有自定义比较逻辑的潜在BUG

小优化建议：不需要把Guid转成字符串再排序，直接比较Guid本身即可，开销更低，优化后示例：

// 2个Guid场景用法
var orderedGuids = guids.OrderBy(g => g).ToList();
dict[Tuple.Create(orderedGuids[0], orderedGuids[1])] = "RandomObj";

// 更推荐用性能更好的ValueTuple（.NET Framework 4.7+、.NET Core全版本支持）
dict[(orderedGuids[0], orderedGuids[1])] = "RandomObj";

如果不想每次写排序逻辑，可以简单封装成工具方法，进一步降低未来扩展成本：

public static class UnorderedGuidKey
{
    // 2个Guid生成键
    public static (Guid, Guid) Create(Guid a, Guid b)
    {
        return a.CompareTo(b) <= 0 ? (a, b) : (b, a);
    }

    // 未来扩展3个Guid只需要加这个方法即可
    public static (Guid, Guid, Guid) Create(Guid a, Guid b, Guid c)
    {
        Span<Guid> guids = stackalloc Guid[3] { a, b, c };
        guids.Sort();
        return (guids[0], guids[1], guids[2]);
    }
}

// 用法
dict[UnorderedGuidKey.Create(guids[0], guids[1])] = "RandomObj";

第二种方案（自定义类+HashSet比较器） #

劣势非常明显：

• 性能差：每次调用Equals和GetHashCode方法都需要新建至少2个HashSet对象，不仅有额外的内存分配，HashSet初始化、集合相等比较的开销远高于直接排序少量Guid，高频操作下GC压力会非常大
• 维护成本高：需要额外维护GuidsModel类和自定义比较器，未来加入第三个Guid时，需要同时修改类的构造函数、属性、比较器逻辑，改动点多容易出问题
• 没有额外优势：该方案能实现的无序匹配需求，第一种方案都能实现，且成本更低

内容的提问来源于stack exchange，提问作者Murtaza Tahir Ali