不能直接用 hash/fnv 或 hash/maphash 做路由哈希，因其不保证跨进程、跨版本、跨平台一致性；maphash 明确不适用于持久化或网络协议，fnv 易因字节处理差异导致结果不一致；MurmurHash3 32位无符号版最稳妥，需严格对齐官方实现的常量、小端序读取、余字节处理及完整混淆步骤。
为什么不能直接用 hash/fnv 或 hash/maphash 做路由哈希
因为它们默认不保证跨进程、跨版本、跨平台的一致性——maphash 明确文档写着“not suitable for persistent data or network protocols”，而 fnv 虽然确定，但对字符串的字节处理（比如是否带长度前缀、大小端）容易被忽略，导致不同服务实例算出不同值。路由哈希必须稳如磐石，哪怕 Go 版本升级、机器重装、Docker 重建，同一字符串输入必须输出同一整数。
手写 MurmurHash3 的 32 位无符号版本最稳妥
MurmurHash3 是工业级选择：速度快、雪崩效果好、实现简单、各语言都有可验证的参考实现。Go 里不用第三方库，自己抄一份 32 位变体即可，重点在于严格对齐官方 C 实现的字节序和常量：
-
const c1 uint32 = 0xcc9e2d51和c2 uint32 = 0x1b873593必须一字不差，错一位就全错 - 每次取 4 字节做
uint32转换时，必须用binary.LittleEndian.Uint32()，不能用unsafe强转——后者依赖机器字节序，x86 和 ARM 结果不同 - 末尾剩余 1–3 字节要单独处理：逐字节左移并异或，不是简单补零再读 uint32
- 最后一步
h ^= h >> 16后还要h * 0x85ebca6b，少一次乘法，分布就明显变差
func murmur32(s string) uint32 {
const (
c1 = 0xcc9e2d51
c2 = 0x1b873593
)
h := uint32(0)
b := []byte(s)
i := 0
for ; i+4 <= len(b); i += 4 {
k := binary.LittleEndian.Uint32(b[i:])
k *= c1
k = (k << 15) | (k >> 17)
k *= c2
h ^= k
}
// 处理余下字节
k := uint32(0)
for j := i; j < len(b); j++ {
k ^= uint32(b[j]) << ((j-i)*8)
}
if k != 0 {
k *= c1
k = (k << 15) | (k >> 17)
k *= c2
h ^= k
}
h ^= uint32(len(b))
h ^= h >> 16
h *= 0x85ebca6b
h ^= h >> 13
h *= 0xc2b2ae35
h ^= h >> 16
return h
}路由时用 hash % shardCount 之前必须检查 shardCount 是否为 2 的幂
如果分片数是质数（比如 97），直接取模会轻微倾斜；但更严重的是——若你后期动态扩容，从 8 扩到 12，所有非 2 的幂的取模都会导致大量 key 重新映射，无法做一致性哈希平滑迁移。所以要么坚持用 2 的幂（4/8/16/32），要么改用 jump consistent hash 这类算法。但 jump hash 对字符串输入需要先转成 uint64，这时又得小心：别用 uint64(hash) 直接截断，要先 uint64(h) ^ uint64(h>>32) 混淆高位低位，否则低 32 位全零会导致大量碰撞。
测试哈希一致性不能只跑一个字符串
单测 murmur32("user_123") == 0xabcdef12 没用，得覆盖边界场景：
立即学习“go语言免费学习笔记（深入）”；
- 空字符串：
murmur32("")应固定返回某值（参考官方测试向量） - 单字节字符串：
murmur32("a")、murmur32("\x00") - 刚好 4 字节、5 字节、7 字节的字符串（触发不同分支）
- 用已知正确实现（如 Python 的
mmh3.hash()）生成 1000 条校验数据，Go 版本必须全对
漏掉任意一种，上线后某个特定用户 ID 就可能永远卡在错误分片上，查起来极难定位。
