应直接使用 github.com/hashicorp/consul/api/consistent 包实现一致性哈希，因其轻量、无依赖、生产验证且不绑定 Consul；禁用 hash(key) % len(nodes)，否则节点变更将导致约 75% 请求重映射、缓存雪崩；必须调用 Rebuild() 且确保导入路径完整、并发写加锁、哈希函数固定为 crc32.ChecksumIEEE。
直接用 github.com/hashicorp/consul/api/consistent，别手写哈希环。它轻量、无依赖、已通过大规模生产验证，且不绑定 Consul 服务本身。
为什么不能用 hash(key) % len(nodes)
这不是一致性哈希，是普通取模哈希。节点从 3 台扩到 4 台时，约 75% 的 key 会重映射，导致：
- 缓存集体失效，引发缓存击穿
- 数据库连接池瞬间打满
- 下游服务响应延迟飙升甚至雪崩
一致性哈希要解决的，是“加一台机器，只动 1/N 的数据”这个硬需求，核心是环状空间（0～2³²−1）+ 顺时针查找 + 虚拟节点，三者缺一不可。
consistent.Map 初始化必须调用 Rebuild()
常见错误是调用了 AddNode() 却没调 Rebuild()，结果 Get() 总是返回空或 panic：
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确顺序：
c := consistent.New()→c.AddNode("node-a", nil)→c.Rebuild() - ❌ 漏掉
Rebuild()，节点根本不会生效 - 导入路径也容易错：
import "github.com/hashicorp/consul/api/consistent"（少或多一级都会编译失败）
并发修改节点时必须加锁
consistent.Map 只保证 Get() 并发读安全；AddNode()、RemoveNode()、Rebuild() 都不是线程安全的：
- 多个 goroutine 同时调用
AddNode()+Rebuild()会触发 slice 并发写 panic - 动态扩缩容场景下，必须用
sync.RWMutex控制写操作 - 读操作可用
RUnlock()，但写操作必须Lock()全局互斥
虚拟节点数设为 100～200，哈希函数固定用 crc32.ChecksumIEEE
分布均匀和跨语言一致性是关键：
- 虚拟节点太少（如 10）→ 易倾斜；太多（如 1000+）→
Rebuild()明显变慢，内存翻倍 - 必须用
crc32.ChecksumIEEE([]byte(key))，别用crc32.Checksum（会 panic） - 哈希值是
uint32，别误当int处理，尤其在边界判断和回绕逻辑中
环上查找本身不自动回绕，sort.Search 返回 len(ring) 时必须手动落到 ring[0]——这个边界漏掉，Get() 就可能返回 nil。
