应选用 maphash：它专为 map 场景设计，速度快、随机性好、防哈希洪水；需手动 seed 以复现结果，跨服务一致时须固定 Seed；crypto/md5 过重，hash/fnv 碰撞高，fmt.Sprintf 转换开销大。
用 hash/maphash 还是 crypto/md5？选错性能差 10 倍
一致性哈希的核心是“相同 key → 相同 hash 值 → 固定节点”，但 Go 里默认的 hash/fnv 不安全（碰撞高），crypto/md5 又太重；实际该用 maphash —— 它专为 map 场景设计，速度快、随机性好、且每次进程重启 hash 结果不一致（防哈希洪水），但你得手动 seed 一次才能复现。
- 别用
fmt.Sprintf("%d", key)+md5.Sum：字符串转换开销大，md5是加密级，没必要 - 要用
maphash.Hash：先h := maphash.New(); h.Write([]byte(key))，再h.Sum64() - 如果需要跨服务/重启保持一致（比如做预分片），必须固定 seed：
h.SetSeed(maphash.Seed{0x1234, 0x5678})，否则每次结果都变
节点环怎么建？别直接用 sort.Slice 排 100 个节点
一致性哈希不是真把节点排成一个圆，而是虚拟节点 + 有序环。真实场景下，节点数少但请求 key 极多，靠线性遍历找“顺时针最近节点”会卡死——必须用二分查找，环结构得是已排序切片 + sort.Search。
- 虚拟节点数别设成 100：太少导致负载不均；建议 100–200，比如每个物理节点映射
node-0#0到node-0#199 - 环结构用
[]uint64存 hash 值，对应节点名用 map 查：ringHashes和hashToNode map[uint64]string - 查节点时别循环：
idx := sort.Search(len(ringHashes), func(i int) bool { return ringHashes[i] >= keyHash })，越界就取ringHashes[0]
sync.Map 能不能缓存环？不能，它不支持范围查询
有人想用 sync.Map 存“key → node”，图省事。但一致性哈希本质是“找大于等于 keyHash 的最小环值”，sync.Map 没法做二分或范围 scan，反而逼你加锁遍历，吞吐直接崩。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 环结构本身是只读的（增删节点才重建），用普通
[]uint64+sync.RWMutex保护重建过程就够了 - 高频读场景下，把
ringHashes和hashToNode都声明为包级变量，初始化后只读，零额外锁开销 - 如果节点动态扩缩频繁，别每改一次就全量重建环；可考虑增量更新 + 版本号控制，但小规模集群直接 reload 更稳
为什么加了虚拟节点还是不均？检查 key 分布和 hash 位宽
常见现象：10 个节点，压测发现 3 个占 70% 流量。问题往往不在算法，而在 key 本身分布倾斜（比如大量 user_0001）或 hash 结果没充分利用 64 位空间。
立即学习“go语言免费学习笔记（深入）”；
- 打印前 100 个 key 的
h.Sum64() % 1000，看是否集中在某几段 —— 如果集中，说明原始 key 差异性低，得加盐（比如拼上服务名或时间戳前缀） - 别用
int(hash % uint64(len(nodes)))：这是取模哈希，不是一致性哈希；必须走环查找逻辑 - 确保用的是
uint64环，别降级成int32或截断低 32 位，否则环精度崩坏，等效节点数锐减
真正难的不是写对算法，是让 key 的 hash 在环上“撒得开”——这取决于你的业务 key 长什么样，以及有没有在 hash 前悄悄引入偏见。
