应选用hash/fnv：它轻量（纯位运算）、可复现、冲突可控，适合分桶；crypto/md5过重，maphash需显式setseed且难管理一致性，均不适用。
为什么用 hash/fnv 而不是 crypto/md5 或 hash/maphash
因为分桶场景不需要密码学安全性，只求快、可复现、冲突率可控。hash/fnv 是非加密哈希，计算极轻量（纯位运算+乘法），且 Go 标准库已内置、无需额外依赖；而 crypto/md5 过重，hash/maphash 默认不保证跨进程/重启一致性（需显式 SetSeed 且 seed 难管理），不适合做长期稳定的分桶依据。
-
fnv.New32()和fnv.New64()输出确定，同一输入在任意 Go 版本/平台结果一致 - 对短字符串（如用户 ID、路径前缀）哈希速度比
md5.Sum快 10 倍以上（实测 100ns vs 1.2μs） - 注意：
hash/fnv不是线程安全的，每次哈希必须新建实例或加锁复用
如何正确构造 FNV 哈希值并映射到桶索引
直接调用 Sum32() 或 Sum64() 前必须先 Write()，否则返回 0；映射到 N 个桶时，不能简单用 % N——当 N 不是 2 的幂时，低比特分布不均会导致桶倾斜。
- 推荐用
hash & (N - 1)，但仅限N是 2 的幂（如 8、16、32） - 若
N任意（如 7、100），改用int(hash) % N，但需确保hash是有符号整型转换（int32→int可能截断，建议用int64(hash.Sum64())） - 示例：分 16 个桶
h := fnv.New64()
h.Write([]byte("user_12345"))
bucket := int(h.Sum64()) & 0xf // 等价于 % 16，更快且分布更均匀
常见错误：复用 hash.Hash 实例导致哈希值污染
hash/fnv 实例内部维护状态，Write() 是累加的。如果把同一个 fnv.Hash64 实例反复用于不同 key，第二次 Sum64() 实际是 “key1 + key2” 的哈希，而非单独 key2 的。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 错误写法：
h.Reset()后继续用同一实例——Reset()在hash/fnv中只是重置为初始种子，但无法清除已写入的字节流状态（它没有缓冲区，Reset 仅重置内部数值） - 正确做法：每次哈希都新建实例，或封装成函数避免误用
- 轻量封装示例：
func fnv64Bucket(key string, buckets int) int {
h := fnv.New64()
h.Write([]byte(key))
return int(h.Sum64()) & (buckets - 1)
}
什么时候该考虑换方案
当发现桶分布严重不均（比如某桶承载 30% 流量），别急着调参——先确认是否 key 本身有强规律性（如全是 "order_20240101_00001" 这类格式）。fnv 对连续数字后缀敏感，此时可加盐（salt）或改用 xxhash（第三方但更快更均匀）。
- 简单加盐：在
Write()前插入固定字节，如h.Write([]byte("myapp_salt")) - 若已用
hash/maphash且需要跨进程一致性，务必在初始化时调用h.SetSeed(0xdeadbeef)，否则默认 seed 来自runtime.memhash，不可预测 - 注意：
fnv对大小写敏感，"User"和"user"哈希完全不同——若业务要求忽略大小写，记得先strings.ToLower()
分桶逻辑一旦上线，hash 函数和 salt 就不能变，否则历史数据会错配到新桶。这点比性能更重要，容易被忽略。
