轮询算法在Go微服务中必须用atomic.Int64维护索引，否则高并发下必然打偏；因int++非原子操作，多goroutine同时读-改-写会导致重复选节点、越界panic或空地址；还需配合健康检查、快照长度取模、索引重置及退避机制。
轮询算法在 Go 微服务中必须用 atomic.Int32 或 atomic.Int64 维护索引，否则高并发下必然打偏——这不是“可能出错”，而是“一定出错”。
为什么裸写 int++ % len(servers) 会崩
多个 goroutine 同时执行 index++ 时，底层是读-改-写三步操作，非原子。常见现象是：两个请求拿到同一个 index 值，结果都选中第一台机器，其余节点长期空闲；更糟的是，当实例列表动态增删后，取模运算若仍用旧长度，会 panic 或越界返回空地址。
- 别用普通
int变量 +sync.Mutex包裹——锁争用会成为 QPS 瓶颈 - 别在
Next()里每次重新计算len(servers)后直接取模——列表更新和取模不是原子操作，中间可能被替换 - 必须先
Load()当前索引，再Add(1)，最后对**快照长度**取模
http.RoundTripper 中嵌入轮询的实操要点
这是 HTTP 客户端最轻量、最可控的轮询落地方式，但容易忽略连接复用与故障隔离。
- 不能复用
http.DefaultTransport：它无状态，每次请求都独立走 RoundTrip，无法维持轮询上下文 - 自定义
RoundTripper必须持有atomic.Int64索引和instances []string快照（不是指针！） - 每次
RoundTrip前，先按快照长度取模选地址，再构造*url.URL并调用底层Transport.RoundTrip - 遇到
connection refused或context.DeadlineExceeded，需显式将该地址加入退避 map（如sync.Map），并在选地址时跳过 -
Transport.MaxIdleConnsPerHost至少设为 100，否则连接池太小，轮询效果被复用逻辑掩盖
gRPC 的 round_robin 不是开箱即用的
从 gRPC-Go v1.27 起，round_robin 已默认禁用，且依赖 resolver 返回多地址 + 显式 service config，缺一不可。
立即学习“go语言免费学习笔记（深入）”；
- 目标地址必须是可解析为多个后端的格式，例如
"dns:///user-service.default.svc.cluster.local"；硬编码"10.0.1.1:8080,10.0.1.2:8080"用passthrough:///前缀会 panic，错误信息是"no load balancing policy configured" - 必须传入
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy":"round_robin"}`)，仅设grpc.WithBalancerName("round_robin")无效 -
round_robin是连接粒度的：一个ClientConn建立后，固定轮询其内部子连接，不会每个 RPC 都重新选节点 - resolver 返回的地址若未带健康状态（如没配
HealthCheck），gRPC 不会自动剔除失败节点——得自己实现watch或定期探测
健康检查不是可选项，而是轮询的前提
没有健康检查的轮询，等于把请求随机扔给死节点。真实场景里，存活 ≠ 可用。
- 不能只依赖注册中心的 TTL 心跳：节点进程卡死、goroutine 全阻塞时，Consul/Etcd 仍认为它“存活”
- 必须起独立 goroutine，定期对每个实例发
GET /health，超时或非 200 就标记为不可用 - 实例列表更新时，要重置轮询索引（
atomic.StoreInt64(&idx, 0)），否则新列表长度变短，旧索引可能越界 - 如果所有节点都不可用，
Next()应返回nil或 panic，而不是静默 fallback 到第一个——这会让上游误判为“有服务”，掩盖问题
轮询本身很简单，真正难的是怎么让它在节点上下线、网络抖动、进程卡死这些真实故障下不丢请求、不雪崩、不假死。多数翻车点不在算法，而在健康状态与调度逻辑的耦合松散——比如健康检查更新了，轮询器却还在用旧快照；或者退避时间没做 jitter，导致大量请求在同一秒涌向刚恢复的节点。
