Go HTTP服务实现同一用户总落到同一台后端需依赖外部负载均衡器（如Nginx基于cookie或ip_hash）或应用层一致性哈希路由；禁用内存map存IP映射，须用动态加载节点列表、合理设置虚拟节点数（如100×实例数）、原子更新ring、颁发稳定session_id并安全传输。
Go HTTP 服务怎么让同一个用户总落到同一台后端？
Sticky Session 不是 Go 标准库直接支持的模式，得靠外部负载均衡器（比如 Nginx、HAProxy）或应用层自己做路由控制。Go 本身只管处理请求，不维护“会话归属”这个状态映射关系。
常见错误是试图在 http.ServeMux 或中间件里用内存 map 记录 IP → 实例，结果发现：集群下各实例 map 不同步、重启丢数据、没考虑客户端走代理导致 RemoteAddr 失真。
- 真正可行的路径只有两条：由 LB 做基于 cookie 或源 IP 的粘性分发；或者业务层主动把 session ID 和后端节点绑定，再通过一致性哈希等策略路由
- 如果 LB 不支持 sticky（比如某些云厂商的四层 SLB），那就只能退到应用层路由——但必须把节点拓扑、健康状态、hash 算法都自己管起来
-
net/http没有内置“转发请求到指定后端”的能力，得用http.RoundTripper+http.Client手动代理，注意超时、连接复用、TLS 配置
Nginx 配置 sticky session 时 cookie 名和 path 容易写错
很多人配完发现 cookie 没生效，其实是 sticky 指令参数没对上。Nginx 官方 sticky 模块（非默认编译进内核）要求明确指定 cookie 名和 expires，且不认 path=/ 这种写法。
典型错误配置：sticky cookie srv_id expires=1h domain=.example.com path=/; —— path 在 sticky 指令里根本不被识别，会被忽略。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法是：
sticky cookie srv_id expires=1h domain=.example.com;，path 由后端应用自己控制 Set-Cookie 头 - 如果用的是
ip_hash，那根本不用 cookie，但缺点是 NAT 环境下多个用户共用一个出口 IP 就全挤到一台后端 - 用
hash $cookie_session_id consistent;更灵活，但需要前端先发一次带session_id的请求，否则 hash key 为空，会 fallback 到轮询
Go 里实现一致性哈希路由要避开虚拟节点数设太小
想在 Go 应用里自己做 sticky 路由，最常用的是 github.com/cespare/xxhash/v2 + github.com/hashicorp/go-memdb 或手写 ring。但虚拟节点数（replicas）设成 100 或 200 是常见坑——实际部署 3–5 台后端时，分布严重不均。
现象是：压测发现某台 CPU 90%，其他才 30%，日志里看到大量请求 hash 到同一个物理节点。
- 建议 replicas 至少设为
100 * len(servers)，比如 4 台后端就用 400，才能让环上散列足够均匀 - 别用
time.Now().UnixNano()当 seed，会导致每次启动哈希顺序固定，无法热扩容；应从配置或服务发现中动态加载节点列表并排序后再建环 - 更新节点列表时不能直接替换 ring 对象，要用原子指针切换（
atomic.StorePointer），否则并发请求可能看到部分新旧混合状态
Session ID 从哪来？别直接读 r.RemoteAddr
很多初学者以为拿客户端 IP 就能做 sticky，但在 Kubernetes Ingress、CDN、AWS ALB 后面，r.RemoteAddr 是上一跳代理的地址，不是真实用户 IP；而 X-Forwarded-For 又可能被伪造。
真正可靠的方式是：由登录接口颁发一个短期有效的 session_id（JWT 或加密字符串），存在 HttpOnly cookie 里，后续所有请求都带这个 ID，后端用它做 hash key。
- 千万别用
uuid.New()每次生成新 ID——那就不 sticky 了；ID 必须在首次请求时确定，并在后续请求中稳定复用 - 如果前端是 SPA，注意 fetch 默认不带 cookie，要加
credentials: 'include'，否则后端收不到session_id - 加密 session ID 时别用硬编码密钥，Key 要从环境变量或 KMS 加载，且定期轮换；否则一旦泄露，攻击者可伪造任意用户路由
真正的难点不在算法，而在状态同步和边界控制：LB 的 sticky 规则、Go 服务的健康探测、session ID 的生命周期管理，三者稍有错位，就会出现“明明设了 sticky 却跳节点”的情况。
