直接用 hash(key) % len(nodes) 会导致节点变更时大量请求重映射，引发缓存雪崩；crc32.ChecksumIEEE 是唯一推荐的哈希函数，因其输出 uint32、跨语言一致、零分配、低碰撞；sort.Search 查环需兜底空环、回绕和碰撞；consul/consistent 需手动 Rebuild 且非线程安全；虚拟节点数宜设 20–60，须用确定性哈希去重。
直接用 hash(key) % len(nodes) 做路由，不是一致性哈希，是缓存雪崩的起点——节点从 3 台变 4 台，约 75% 的请求会重映射，Redis 命中率断崖下跌，DB QPS 翻三倍。
为什么 crc32.ChecksumIEEE 是唯一推荐的哈希函数
一致性哈希环的坐标必须是 uint32，且要跨语言一致、无分配、低碰撞。crc32.ChecksumIEEE([]byte(key)) 天然满足：输出就是 uint32，Go 标准库内置最优查表，调用零开销，Java/Python/JS 默认也用它，避免“同一 key 在不同服务落到不同节点”的线上事故。
常见踩坑：
-
crc32.Checksum([]byte(key), nil)会 panic，必须传表或改用ChecksumIEEE -
md5.Sum或sha256.Sum256：加密级哈希，慢、分配多、输出非uint32，纯属浪费 -
hash/fnv.New32a()：无 seed 控制，易被恶意 key 扎堆攻击，不适合生产路由 -
maphash.Hash：输出uint64，截断或 mod 2³² 会引入偏差，不推荐用于环坐标
sort.Search 查环时三个边界必须兜底
sort.Search 返回的是索引，不是值；它不检查环是否为空，也不自动回绕。漏掉任一条件，运行时 panic 或返回空节点是常态。
立即学习“go语言免费学习笔记（深入）”；
安全写法必须包含：
- 环为空：
if len(ring) == 0提前返回 error 或 panic - key 哈希值大于所有节点：
sort.Search返回len(ring)，需用i % len(ring)回绕到第一个节点 - 节点哈希碰撞：多个节点落在同一位置，
sort.Search仍能返回第一个 ≥ key 的索引，但添加节点时建议跳过重复值，避免无效冗余
典型代码片段：
i := sort.Search(len(ring), func(j int) bool { return ring[j] >= keyHash }); return ring[i%len(ring)]
用 github.com/hashicorp/consul/api/consistent 要注意三件事
这个包轻量（不到 300 行）、无依赖、已生产验证，但它不是“即插即用”——三个动作漏一不可。
- 导入路径必须写全：
"github.com/hashicorp/consul/api/consistent"，漏掉/api会编译报错 - 增删节点后必须手动调用
c.Rebuild()，否则c.Get()仍查旧环，结果完全不变 -
consistent.Map不是线程安全的：多 goroutine 同时调用AddNode()或RemoveNode()会 panic，需外层加sync.RWMutex或改用写时复制（copy-on-write）
虚拟节点数不是越多越好，20–60 个更实际
设 100+ 虚拟节点看似更均衡，实测反而拉高延迟：查找耗时从 ~20ns 涨到 ~80ns，CPU cache miss 率陡增，初始化也变慢。小集群（≤5 节点）建议设 20–60；若节点数少于 3，可按 replicas = 100 × 实例数 线性配（如 3 台配 300），否则固定 100 容易倾斜超 40%。
生成虚拟节点 hash 必须用确定性方式：
- 正确：
crc32.ChecksumIEEE([]byte(nodeName + ":" + strconv.Itoa(i))) - 错误：
rand.Uint32()或未设 seed 的rand.NewSource(time.Now().UnixNano())——会导致多个虚拟节点挤在环上同一位置
上线前务必对所有节点及其全部虚拟节点 hash 值做去重检查，确认无碰撞。
