不能用 sync.Map 存 IP→后端映射，因其仅保障单机并发安全，无法实现集群状态同步；用户请求跨节点时映射丢失、NAT 导致出口 IP 冲突、服务重启后黏性失效等问题均源于模型错误——sync.Map 本就不适用于多节点黏性路由场景。
为什么不能用 sync.Map 存 IP → 后端 映射
它只解决单机并发安全，不提供集群状态同步。常见错误现象包括：
- 用户第一次请求落到
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清空，已建立的黏性全部失效，用户被迫重新登录
这些不是“写得不够好”的问题，而是模型错误——sync.Map 根本就不该出现在多节点黏性路由的路径里。
gorilla/sessions 提取 session_id 后怎么路由
必须用 session_id 字符串本身做一致性哈希 key，而不是原始 Cookie 值、r.RemoteAddr 或 X-Forwarded-For。原因：
- 原始 Cookie 没签名，前端可伪造；
session_id经gorilla/sessions签名验证，可信 -
session_id是稳定、唯一、服务端可控的标识，天然适合作为 hash key - 虚拟节点数（
replicas）别硬写 100：3 台后端建议设 300，5 台建议设 500，公式为replicas = 100 × 实例数 - 后端节点列表必须动态加载（如从 etcd/consul 拉取），不能写死；节点上下线时要原子更新整个 ring，不能只增删个别节点
Nginx 的 sticky 指令为什么 cookie 不生效
因为很多人配错了参数。典型错误配置：
sticky cookie srv_id expires=1h domain=.example.com path=/;
path 在 sticky 指令里根本不被识别，会被忽略。正确写法是：
sticky cookie srv_id expires=1h domain=.example.com;
如果你用的是 hash $cookie_session_id consistent;，注意两点：
- 首次请求若没带
session_id，hash key 为空，会 fallback 到轮询；需确保登录后至少一次重定向或响应中 Set-Cookie 成功 -
ip_hash看似简单，但 NAT 环境下多个用户共用一个出口 IP 就全挤到一台后端，实际可用率极低
Go 应用层自己做一致性哈希路由的关键避坑点
真要自己实现，核心不是“能不能 hash”，而是“hash 结果是否稳定、可扩展、可维护”：
- 别用
net/http默认的http.ServeMux做转发入口——它不支持修改 Host、清除 hop-by-hop 头；要用httputil.NewSingleHostReverseProxy+ 自定义Director - 转发前必须清理
req.Header中的Connection、Keep-Alive、Proxy-Authenticate等字段，否则后端可能拒收 - 后端健康检查不能只 ping 端口，要带真实路径探活（如
/healthz），并缓存结果避免每次路由都查 - 一致性哈希库推荐
github.com/hashicorp/consul/api自带的 ring，或手写时用github.com/cespare/xxhash/v2做 hash 函数，别用hash/fnv（分布偏差大）
最常被忽略的一点：节点变更时，ring 更新必须是原子的。你不能在旧 ring 上删一个节点再加一个，而要生成全新 ring 后一次性替换指针——否则中间态会导致部分 session 路由错乱，且无法回滚。
