MinHash是一种概率算法，用于快速估算两个集合的Jaccard相似度；它通过多个独立哈希函数为每个集合生成固定长度签名，以O(k)时间替代直接计算Jaccard所需的O(n)交并操作，显著降低高维稀疏集合（如文档、用户行为）的相似度计算开销。
MinHash 是什么，为什么不用直接算 Jaccard
MinHash 不是 Go 标准库函数，它本质是一套概率算法，用来快速估算两个集合的 Jaccard 相似度（|A ∩ B| / |A ∪ B|），尤其适合文档、词袋、用户行为这类高维稀疏集合。直接算 Jaccard 要求你把所有元素加载进内存再求交并，而 MinHash 只需对每个集合做一次哈希扫描，生成固定长度签名（比如 128 个 uint64），后续比对只需逐位比较签名数组——时间从 O(n) 降到 O(k)，k 是签名长度。
Go 里没现成的 minhash 包，但你可以用 hash/fnv 或 hash/maphash 自建哈希流水线，关键不是“选哪个哈希”，而是保证：同一元素在不同集合中哈希结果一致，且多个哈希函数之间尽量独立。
怎么构造 MinHash 签名（带随机种子的多哈希）
标准做法是用 k 个不同种子的哈希函数，对集合中每个元素分别计算哈希，然后取每个哈希函数下的最小值，组成 k 维签名。Go 中最稳妥的方式是预定义一组 hash.Hash64 实例，每个用不同 seed 初始化：
// 示例：生成 64 维 MinHash 签名
func minHashSignature(elements []string, k int) []uint64 {
sig := make([]uint64, k)
for i := range sig {
sig[i] = math.MaxUint64 // 初始化为最大值
}
h := fnv.New64a()
for _, elem := range elements {
for i := 0; i < k; i++ {
h.Reset()
h.Write([]byte(elem))
h.Write([]byte(fmt.Sprintf("%d", i))) // 加入种子扰动
hashVal := h.Sum64()
if hashVal < sig[i] {
sig[i] = hashVal
}
}
}
return sig
}
注意点：
- 别用
rand.Seed()动态生成种子——会导致签名不可复现；固定 seed 或用i做扰动更可控 - 元素必须是可稳定序列化的，比如字符串或结构体 JSON 字符串；不能传指针或 map（顺序不确定）
- 如果元素本身是整数 ID，直接用
binary.PutUvarint写入字节流，比转 string 更快更准
签名比对时怎么算近似 Jaccard
两个 MinHash 签名的相似度，就是对应位置相等的个数除以总长度：float64(countEqual(sigA, sigB)) / float64(len(sigA))。这不是精确 Jaccard，而是无偏估计，方差随 k 增大而减小。
实操建议：
- 别用
reflect.DeepEqual比签名——慢且不必要；直接 for 循环比较uint64值即可 - k=128 时，估计误差通常在 ±0.05 以内；若业务要求严苛（如去重阈值设 0.95），建议 k ≥ 256
- 如果要做海量签名两两比对，别暴力 O(n²)；改用 LSH（Locality-Sensitive Hashing）分桶，比如用前 4 位签名做桶 ID，只比同桶内候选
常见坑：空集合、重复元素、哈希碰撞
MinHash 对空集合没定义，minHashSignature([]string{}, k) 会返回全 math.MaxUint64 数组，导致与其他任何签名相似度为 0——这反而是合理行为，但你要显式处理空输入，比如提前返回 nil 或 panic 提示。
重复元素不影响结果（因为 min 操作幂等），所以无需预去重，这点比直接算 Jaccard 更省事。
哈希碰撞不是 bug，而是算法前提：MinHash 的理论保证依赖哈希足够均匀。避免用 hash/crc64（分布偏斜），优先选 fnv.New64a 或 maphash.Hash（Go 1.22+，更快且质量好）。如果发现大量签名完全一致但原始集合差异很大，检查是否误用了相同 seed 或漏了扰动字段。
真正容易被忽略的是签名序列化和传输一致性：存数据库或发 HTTP 时，确保用小端序（binary.LittleEndian.PutUint64）写 bytes，并在读取时严格按同样方式解析——否则跨平台或跨语言对接会出错。
