fnv.new64a()是go中非加密哈希首选，64位输出碰撞率低、分布均匀；new32a()仅在内存敏感且可接受略高冲突时选用；必须用sum64()/sum32()匹配类型，多字段哈希需\x00分隔，非2的幂分片数须避免直接%n以防倾斜。
直接用 hash/fnv，别绕弯——它就是 Go 里最省心、最快、最确定的非加密哈希方案，适合缓存键、分片路由、日志 ID 等所有不需要防篡改的场景。
fnv.New32a() 和 fnv.New64a() 怎么选
优先选 fnv.New64a()：64 位输出碰撞概率更低，对短字符串（如 "user_123"）分布更均匀；fnv.New32a() 仅在内存极度敏感（比如嵌入式或每秒百万级 key）且你能接受略高冲突率时考虑。两者性能几乎无差别，但 New64a 的雪崩效应略好，尤其在多字段联合哈希时更稳。
-
fnv.New32()和fnv.New64()是 FNV-1 变体，New32a/New64a是更推荐的 FNV-1a（乘法+异或顺序不同），抗简单模式能力更强 - 别用
fnv.New32()替代fnv.New32a()—— 后者是标准推荐，前者已基本被弃用 - 输出类型必须匹配：用
Sum32()拿uint32，用Sum64()拿uint64；混用会 panic 或返回 0
多个字符串拼接哈希时怎么避免碰撞
绝对不要写 s1 + s2 + s3 再转 []byte —— "ab"+"c" 和 "a"+"bc" 会哈希出同一个值，实测碰撞率高达 12%。
- 正确做法是逐段
Write([]byte(s1))，中间插入明确分隔符，例如h.Write([]byte{0}) - 分隔符选
\x00最安全（几乎不会出现在业务字符串中），比"|"或":"更可靠 - 不要依赖
fmt.Sprintf("%s:%s:%s", a, b, c)—— 字段含冒号、空格或格式变化时，哈希就失效 - 如果字段本身可能含
\x00，改用长度前缀：先h.Write([]byte{byte(len(s1))})，再h.Write([]byte(s1))
哈希后映射到 N 个桶，为什么不能直接 % N
当 N 不是 2 的幂时，hash % N 会让低比特主导结果，导致桶分布严重倾斜——比如 N=100，hash & 0x63（即 % 100 的位运算近似）实际等价于 hash & 99，但这是错的，因为 99 不是 2ⁿ−1。
- 若
N是 2 的幂（如 8、16、32、64），用int(hash.Sum64()) & (N - 1)，快且均匀 - 若
N任意（如 7、100、1000），必须用int(hash.Sum64()) % N，但注意：Sum64()返回uint64，要先转int64再转int，否则溢出 - 更稳妥写法：
int(hash.Sum64()) & 0x7fffffff % N，先取高位 31 位再取模，缓解低位偏斜
复用 hash/fnv 实例为什么总出错
hash/fnv.Hash64 不是“清空就能重用”的对象——它的 Reset() 只重置种子，不丢弃已写入的字节流状态。同一个实例连续哈希两个 key，第二个结果其实是 key1+key2 的哈希。
- 最简单解法：每次哈希都新建实例，开销极小（
new几个字节，100ns 级） - 想复用？封装成函数或用
sync.Pool，但池中实例仍需在Get后手动Reset()并确认没残留状态（其实不如新建） - 千万别在 goroutine 间共享未加锁的
fnv.Hash64实例——它不是线程安全的，Write()和Sum64()并发调用会读到脏数据 - 常见误用：
h.Reset(); h.Write([]byte("a")); fmt.Println(h.Sum64())→ 第二次调用前没Reset()，结果是累积哈希
真正容易被忽略的点是：哈希值的“确定性”不只取决于算法，还取决于字节序列是否严格一致——哪怕一个字段多一个空格、少一个 \x00 分隔符，或跨服务用了不同版本的 Go（虽然 fnv 本身跨版本稳定，但字符串编码细节可能变），结果就不可重现。做分片路由时，这点比性能更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
