一致性哈希必须构建环结构并顺时针查找，不能用hash(key)%len(nodes)；需用sort.search配合手动兜底空环、回绕和虚拟节点去重，推荐crc32哈希及20–60个虚拟节点。
直接用 hash(key) % len(nodes) 就不是一致性哈希，而是取模哈希——节点从 4 台扩到 5 台时，约 75% 的 key 映射会变，缓存雪崩、DB 打满、下游超载是必然结果。真的一致性哈希必须构建环结构，靠顺时针查找 + 虚拟节点实现局部重映射。
为什么 sort.Search 查环必须手动处理回绕和空环
sort.Search 是查哈希环最轻量的方式，但它不理解“环”——它只在升序切片里找第一个 ≥ key 的索引，完全不管首尾相接。漏掉边界处理，GetNode 就会 panic 或返回空。
- 环为空时，
sort.Search返回 0，但ring[0]直接越界 panic；必须先判len(ring) == 0 - key 哈希值大于所有节点哈希值（比如环上最大是
0xfffffffe，key 算出0xffffffff），sort.Search返回len(ring)，此时要回绕到ring[0] - 最终索引必须统一用
i % len(ring)，这是环形数学结构的必然，不是妥协——哪怕i正好等于len(ring)，%也能安全落到0
虚拟节点数设多少才合理：20–60 是生产平衡点
虚拟节点太少（如每物理节点只配 5 个），数据倾斜明显；太多（如 1000+），环变大导致 CPU cache miss 率陡增，sort.Search 延迟翻倍。20–60 是多数服务验证过的平衡区间。
- 节点数少于 5 台时，建议设 40–60，避免冷热不均
- 别用
math/rand生成虚拟节点名：没调Seed()会导致所有虚拟节点 hash 值扎堆；正确做法是用crc32.ChecksumIEEE([]byte(nodeName + "-" + strconv.Itoa(i)))，确定性且跨语言一致 - 虚拟节点名必须带序号后缀（如
"node-a-0"、"node-a-1"），否则无法展开权重、也无法去重校验
用 github.com/hashicorp/consul/api/consistent 别踩这三个坑
这个包轻量、无依赖、已生产验证，但导入、使用、并发三处极易出错。
- 导入路径必须写全：
github.com/hashicorp/consul/api/consistent，写成github.com/hashicorp/consul/api或漏掉/consistent都会报错 - 增删节点后必须显式调用
c.Rebuild()，否则c.Get(key)仍查旧环，行为不可预期 -
consistent.Map非线程安全：多 goroutine 同时AddNode会 panic；读多写少场景下，不能只靠sync.RWMutex锁整个结构，应封装为 copy-on-write 模式，用atomic.Value替换环指针
环结构本身简单，但边界条件、虚拟节点生成逻辑、并发模型这三点，才是实际落地时最容易被忽略也最常出问题的地方。写完 GetNode 后，务必用空环、单节点环、key 大于所有节点这三种 case 手动测一遍——比跑单元测试更能暴露真实问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
