go http客户端实现轮询负载均衡需用atomic维护全局索引，避免每次新建实例重置；节点下线应标记不可用而非删除切片；math/rand.perm不适用于每请求随机，应改用rand.intn；负载均衡逻辑必须在请求前确定url，由client复用transport；轮询需配合健康检查与权重支持才实用。
Go HTTP客户端怎么实现轮询（Round Robin）负载均衡
轮询不是靠服务端自动分发，而是客户端自己维护一个后端节点列表，每次请求时按顺序取下一个节点。关键在于状态要跨请求保持，不能每次新建一个 RoundRobinLB 实例就重置索引。
- 用
sync/atomic操作一个全局计数器，避免锁开销；如果后端列表会动态变更，就得升级为sync.RWMutex保护切片读写 - 注意节点下线时的处理：不要简单删掉切片元素（会破坏轮询顺序），推荐标记为不可用 + 跳过，或重建索引映射
- 示例中常见错误是把
index定义在函数内：func next() { var index int }——每次调用都是 0，根本不是轮询
Go里用math/rand.Perm做随机负载均衡靠谱吗
不靠谱，math/rand.Perm 生成的是「一次打乱的全排列」，不是「每次独立随机选一个」。它适合初始化时打乱节点顺序，但不能直接用于每请求随机选择。
- 真正需要的是每请求调用
rand.Intn(len(backends))，且必须用rand.New(rand.NewSource(time.Now().UnixNano()))初始化独立实例，否则多个 goroutine 共享默认全局rand会竞态 - 如果用
rand.Seed()（已弃用），或重复用同一个 seed，会导致所有请求选到相同节点 - 性能上，
Intn比Perm轻量得多；后者每次都要分配和填充切片，对高频请求是浪费
HTTP Transport层能不能复用连接做负载均衡
不能。Go 的 http.Transport 本身不感知后端列表，它只管单个目标地址的连接池（keep-alive、空闲连接复用）。负载均衡逻辑必须在发起请求前就决定好 *http.Request.URL 的 Host 和 Port。
- 常见错误：把多个后端地址都配进同一个
Transport，幻想它能自动分发——它只会报no such host或连错地址 - 正确做法是：先选节点（轮询/随机），再构造新
*url.URL，最后用同一个http.Client（复用 Transport）发请求 - 如果你用了
http.ReverseProxy，它的Director函数就是干这事的：修改req.URL，指向选定的后端
为什么简单轮询在真实场景中容易出问题
因为轮询只看“请求次数”，完全不考虑后端实际负载、响应延迟或失败率。一个节点卡住或慢了，轮询照发，雪球越滚越大。
立即学习“go语言免费学习笔记（深入）”；
- 健康检查必须配套：比如对每个节点定期发
HEAD /health，失败超过阈值就临时剔除，恢复后再加回 - 权重支持不是可选功能：有些节点配置高，应该多分担；硬编码等权重轮询会让强节点闲置、弱节点压垮
- 一致性哈希更适合有状态服务（如缓存），但 Go 标准库没内置，得用
github.com/hashicorp/consul/api或自己实现hash/fnv+ 虚拟节点
轮询和随机只是起点，真实系统里它们往往只是兜底策略，上面还得叠一层基于延迟或成功率的动态调整——这点很容易被忽略，直到某次故障才暴露出来。
