一致性哈希环必须用uint32构建，空间严格定义为0～2³²−1；int会导致负数绕回、float64丢失精度、uint64超出边界致二分查找失效；crc32.ChecksumIEEE直接返回uint32，应优先采用。
哈希环必须用 uint32 构建，别用 int 或 float
环空间定义为 0～2³²−1 是一致性哈希的硬性前提，不是可选项。用 int 会导致负数哈希值绕回高位，float64 会丢失精度，uint64 则超出环边界、二分查找失效。
Go 标准库 crc32.ChecksumIEEE 返回的就是 uint32，直接拿来用即可：
hash := crc32.ChecksumIEEE([]byte(key))
常见错误现象：
- 节点增删后
GetNode总返回同一个节点：哈希值被转成int后符号位翻转，导致大量虚拟节点挤在环前端 -
sort.Search查不到节点、返回越界索引：环切片里存的是int，但查找时传入uint32，类型不匹配导致比较逻辑错乱
虚拟节点数设 20～60，别盲目堆到 100+
虚拟节点越多，分布越均匀，但代价是内存占用和查找延迟同步上升。实测在 5～20 节点规模下，NumberOfReplicas = 40 是性价比拐点；超过 100 后，L1 cache miss 率明显升高，GetNode 平均耗时反升 15%～20%。
立即学习“go语言免费学习笔记（深入）”；
使用建议：
- 节点数 ≤ 5：设 40～60，防冷热不均
- 节点数 6～20：设 20～40，兼顾均衡与性能
- 节点数 ≥ 50：设 10～20 即可，环太大反而拖慢
sort.Search - 别用
math/rand生成虚拟节点名：未初始化种子会导致所有副本 hash 值相同，等效于没加虚拟节点
正确扰动方式：hashKey(fmt.Sprintf("%s#%d", nodeID, i))，其中 hashKey 用 crc32 或 fnv.New32a。
环查找必须处理“回绕”边界，否则空环或最大值时 panic
sort.Search 返回的是插入位置索引，可能等于切片长度。若不检查，ring[idx] 直接越界；若环为空，它返回 0，ring[0] 也 panic。
安全写法只有两步：
- 先判空：
if len(hr.hashOrder) == 0 { return nil, errors.New("no nodes") } - 再取模：
idx := sort.Search(len(hr.hashOrder), func(i int) bool { return hr.hashOrder[i] >= hash })，然后用hr.hashOrder[idx%len(hr.hashOrder)]
漏掉取模是线上最常见 panic 来源之一——尤其在节点刚移除、环尚未重建完成时，idx 恰好等于 len(hr.hashOrder)，一查就崩。
并发读写必须用 copy-on-write，RWMutex 会卡死 GetNode
读多写少是负载均衡场景的典型特征。sync.RWMutex 对整个环加锁，一次 AddNode 就会让所有并发 GetNode 阻塞，QPS 断崖下跌。
生产级做法是：
- 每次变更都新建环结构（
[]uint32+map[uint32]string） - 用
atomic.Value原子替换指针：var ring atomic.Value，写时ring.Store(newRing)，读时ring.Load().(*consistentRing) -
AddNode/RemoveNode内只做内存结构变更，健康检查等 IO 操作前置到管理端
consistency 库的 Rebuild() 不是自动触发的——调了 AddNode 之后忘了 Rebuild()，新节点永远不会生效，这是新手最常踩的坑。
