不能用sync.Map存IP→后端映射，因其仅保障单机并发安全，无法解决分布式状态同步问题：用户请求跨节点时映射丢失、NAT导致IP统一、节点重启清空缓存，致使黏性路由失效、用户被迫重新登录。
为什么不能用 sync.Map 存 IP → 后端映射
因为 sync.Map 根本不解决分布式状态同步问题，只保单机并发安全。真实线上会立刻翻车：
- 用户第一次请求落到
node-1，sync.Map记了"192.168.1.100" → "node-1"；第二次请求被 LB 转到node-2，查不到映射，fallback 到轮询 - 所有用户走 CDN 或 NAT 时，
r.RemoteAddr变成统一出口 IP（如"100.64.0.1:54321"），全部 hash 到同一台后端 - 任意节点重启，
sync.Map清空，所有已建立的黏性路由失效，用户被迫重新登录
这不是配置问题，是模型错误——单机内存无法承载跨节点的 Session 黏性语义。
crc32.ChecksumIEEE 必须用对，别写成 crc32.Checksum
一致性哈希环上节点和 key 的分布均匀性，直接取决于哈希函数输出是否稳定、低碰撞。Go 标准库中 crc32.ChecksumIEEE 是事实标准：
- 它内置最优查表，调用简洁：
crc32.ChecksumIEEE([]byte(key)) - 别手滑写成
crc32.Checksum([]byte(key), nil)—— 会 panic；也别漏掉IEEE后缀，否则默认用非标准实现，跨语言（Java/Python/JS）结果不一致 - 返回值是
uint32，后续做环查找或取模时别误当int用，尤其在比较和%运算中容易越界
sort.Search 查环必须兜住三个边界
哈希环本质是升序 []uint32，sort.Search 是最轻量、最安全的查找方式，但生产环境必须手动处理以下三种情况：
- 环为空：
len(ring) == 0时不能硬算i % len(ring)，应提前返回 error 或 panic - key 比所有节点都大：
sort.Search返回len(ring)，需回绕到ring[0] - 节点哈希碰撞：多个节点映射到同一位置，
sort.Search仍能正确返回第一个 ≥ key 的索引，但添加节点时建议跳过重复值，避免无效冗余
典型安全写法：i := sort.Search(len(ring), func(j int) bool { return ring[j] >= keyHash }); return ring[i%len(ring)] —— 这个 % 不是偷懒，是环形结构的数学必然。
虚拟节点数不是拍脑袋定 100，要按实例数线性配
小集群下设固定 100 个虚拟节点，会导致严重倾斜。实测 3 台后端用 100 虚拟节点，分布偏差常超 40%；真正可用的公式是：replicas = 100 × 实例数：
- 3 台后端 → 设 300 个虚拟节点
- 5 台后端 → 设 500 个虚拟节点
- 节点增减时，重映射比例可压到 1% 以内；而普通取模在节点数从 3→4 时，约 75% 的 key 映射关系会变
这个数字背后是统计收敛性——太少则环上空洞多，太多则 ring slice 内存占用和查找开销上升，没意义地拉高 GC 压力。
真正难的不是写对哈希环，而是让 session_id 提取、hash 计算、环查找、fallback 策略这四步全程可控。任何一环用了 r.RemoteAddr 或没验签的原始 Cookie，整个黏性就形同虚设。
