go负载均衡需自行实现，轮询用atomic避免竞态，加权轮询须动态累积与归一化currentweight，最小连接数应统计活跃请求数而非tcp连接，健康检查须异步goroutine维护快照。
Go语言框架本身不内置负载均衡逻辑，所有客户端侧的负载均衡都得自己编码控制——无论是轮询、加权轮询还是最小连接数，都只是对后端实例列表做一次“选节点”动作，然后把请求发过去。没有框架会自动感知节点延迟、CPU占用或队列积压。
轮询策略为什么用 atomic.AddUint64 而不是普通变量
多个 goroutine 并发调用 Next() 时，如果只用 int 类型的 index 字段并直接递增，会出现竞态：两个 goroutine 同时读到 index == 3，各自加 1 写回，最终变成 4 而不是预期的 5。
使用 atomic.AddUint64 可以保证该操作是原子的，无需加锁就能安全递增。但要注意：
- 取模运算
% len(servers)必须在原子操作之后立即进行，否则可能因servers切片被并发修改（如热更新）导致 panic - 如果服务列表会动态变更，不能只靠原子索引，得配合
sync.RWMutex保护整个列表读写 -
uint64对len(servers)做模运算是安全的，但若列表为空，len()返回 0，会导致除零 panic，必须提前校验
加权轮询中 currentWeight 和 gcd 的实际作用
标准加权轮询（WRR）不是简单地“每个节点按权重连发 N 次”，而是要避免请求扎堆。它通过维护一个全局 currentWeight，每次选节点时给每个节点计算 weight - currentWeight，选差值最大的那个，再更新 currentWeight。GCD（最大公约数）用于归一化权重，防止小权重节点长期得不到调度。
比如权重为 [5, 3, 1]，GCD 是 1，但若权重是 [100, 50, 10]，不约简会导致 currentWeight 累积过慢，低权节点饥饿。所以实际实现中会先算 GCD，再用 weight / gcd 作为有效权重参与比较。
常见错误：
- 直接用浮点数做权重比较，引入精度误差
- 每轮重置
currentWeight，退化成静态轮询 - 没做权重归一化，在容器环境里权重设成 CPU 核数（如 8），结果所有实例都报告 “8”，彻底失效
最小连接数策略为何不能只依赖 net.Conn 数量
HTTP/1.1 默认复用连接，一个 *http.Client 实例底层可能只建几个 TCP 连接就复用到底；而 HTTP/2 更是单连接承载多路请求。此时统计 net.Conn 数量完全不能反映真实负载。
真正该监控的是：
- 每个后端实例当前正在处理的 HTTP 请求计数（需服务端配合上报或通过中间件埋点）
- 最近 1 秒内该实例的平均响应延迟（
time.Since(start)） - 实例内存使用率或 GC pause 时间占比（需
runtime.ReadMemStats或 pprof）
如果硬要在客户端做最小连接数，推荐用 sync.Map 维护每个实例的活跃请求数，每次请求开始前 LoadOrStore +1，结束时 CompareAndSwap -1，并设置超时清理机制，否则 goroutine panic 会导致计数泄漏。
健康检查与故障剔除最容易被忽略的细节
很多实现只在初始化时拉一次服务列表，后续完全不探测节点是否存活。结果是：某个实例已崩溃，但负载均衡器还在持续转发请求，直到超时失败才 fallback，用户体验断层明显。
可行做法：
- 用独立 goroutine 每 5–10 秒对每个后端发轻量
HEAD /health，成功则标记healthy = true，连续 3 次失败则标记healthy = false - 在
Next()中跳过healthy == false的节点，若全部不可用，可降级为随机选一个（避免全盘拒绝） - 不要在每次请求前同步做健康检查，那会把 RT 直接拉高几十毫秒
- 注意 DNS 缓存：如果后端地址是域名，
net.DefaultResolver默认缓存 TTL，节点下线后旧 IP 仍可能被复用数分钟
最麻烦的其实是“恢复感知”——节点重启后，你得让它悄悄承接少量流量预热，而不是瞬间打满。这需要带权重的渐进式恢复逻辑，不是简单改个布尔标志就能解决的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
