我希望比较哈希来检查冲突（是的，我知道这很耗时，但没关系）。在检查冲突时，需要比较哈希值。最好的方法是在变量中使用单个哈希值进行比较，或者列出之前生成的所有哈希值并将最新的哈希值与列表中的每个项目进行比较。
我更喜欢第一个选项，因为它更快，但是有推荐的方法吗？使用第一种方法是否不太可能发现碰撞？
【问题讨论】：
hash是什么类型的？
MD5 开始。技术？
标签： hash
最好的方法是在变量中使用单个哈希值进行比较，或者将之前生成的所有哈希值的列表与列表中的每个项目进行比较。
都没有。
我更喜欢第一个选项，因为它更快，但是有推荐的方法吗？
我不明白您为什么认为第一种方法可能有效，但是您还没有完全解释您的情况。尽管如此，如果您想检测重复的哈希值，您确实需要跟踪已经看到的哈希值：要做到这一点，您不想通过列表进行线性搜索，并且应该使用集合容器来存储看到的哈希；哈希表 - 正如 gnasher729 几小时前在评论中所建议的那样 - 将提供 O(1) 性能，例如在 C++ 中，您的哈希值是 64 位 std::unordered_set<uint64_t>)，或用于 O(logN) 性能的平衡二叉树（例如 C++ std::set<uint64_t>）。
使用第一种方法是否不太可能发现碰撞？
你很可能会错过碰撞。
说了这么多，你可能想重新审视你的前提。良好（加密质量）散列函数产生冲突的几率接近"birthday paradox" 描述的几率。根据经验，如果您有 2^N 个不同的值来散列，那么如果您的散列宽大于 2*N 位，则 统计上不太可能发生冲突：如果您允许足够的“舒适度” “，比起让你的程序看到碰撞，你更有可能被流星击中头部。您提到了 MD5，所以我期望 128 位：除非您存储的值是千万亿或更多（字面意思），否则忽略冲突的可能性是非常安全的。
请注意哈希值的一个重要用途，其中由于不同的原因而更频繁地发生冲突，那就是在哈希表中，即使是非冲突的哈希值也可能在“包装”后在同一个存储桶索引处发生冲突 - 通常当N 是桶的数量时，h % N。一般来说，忽略哈希表中潜在的冲突是不切实际的，尝试也是不明智的。
【讨论】：