Go负载均衡需兼顾并发安全、权重精度与健康检查：轮询须用atomic.Int32或sync.Mutex防竞态；加权轮询推荐平滑算法避免扎堆；随机必须基于健康节点列表，且禁用全局rand.Seed。
Go 语言实现负载均衡算法不难，但直接照搬教科书式写法容易在线上出问题：比如并发下 requestIndex 竞态、权重累积误差导致分配倾斜、随机选节点没做去重或健康检查兜底。核心是「状态管理」和「调度语义一致性」。
轮询（RoundRobin）必须用原子操作或互斥锁保护索引
Go 没有内置的全局原子计数器变量，手写 int + ++ 在高并发下必然错乱。错误写法：index = (curIndex++) % len(servers)；正确做法是用 atomic.AddInt32 或 sync.Mutex。
常见错误现象：多个 goroutine 同时读到相同 curIndex，返回同一台服务器，造成流量打偏。
- 推荐用
atomic.Int32（Go 1.19+），初始化为0，每次调用Load()后Add(1) - 如果兼容老版本，用
sync/atomic的atomic.AddInt32，注意参数类型必须是*int32 - 别在循环里直接用
%计算下标——先atomic.LoadInt32，再取模，最后atomic.AddInt32，顺序不能反
加权轮询（Weighted Round Robin）要避免“扎堆”和整数截断误差
简单按权重重复追加服务器到列表（如权重 3 就塞 3 次）看似直观，但会导致高权重节点被连续调度，引发瞬时压力；而纯比例计算又容易因浮点或整数除法丢失精度。
平滑加权轮询（Smooth Weighted RR）是更稳妥的选择，它维护每个节点的「当前权重」和「有效权重」，每次调度后动态调整。
- 每个节点保存
weight（配置值）和currentWeight（运行时累加值） - 每次选节点前，对所有节点执行
currentWeight += weight - 选
currentWeight最大的节点，然后对其currentWeight -= totalWeight - totalWeight 是所有节点
weight之和，必须是整数且固定不变
这个逻辑能保证长期分布严格符合权重比，且单次调度不会连续命中同一节点。
随机（Random）不能只靠 rand.Intn，得加健康检查兜底
rand.Intn(len(servers)) 看似一行搞定，但实际部署中，随机算法最常被忽略的是「失效节点隔离」。如果某台服务器已宕机，随机仍可能选中它，导致请求失败率陡增。
- 必须配合健康检查结果过滤——只在
healthyServers切片里随机，而不是原始全量列表 -
rand.Seed在 Go 1.20+ 已废弃，应使用rand.New(rand.NewSource(time.Now().UnixNano()))构造独立实例，避免多 goroutine 共享 seed 导致序列重复 - 如果要求「同一客户端尽量粘性」，随机就不合适，得切到 IP 哈希或会话保持，这点常被误认为“随机也能凑合”
真实服务中，轮询类算法必须和健康检查联动
轮询、加权轮询、随机这些静态算法本身不感知后端状态。线上最常见的故障不是算法写错，而是「服务器挂了但还在调度列表里」。
关键点在于：调度器拿到的服务器列表，必须是经过最近一次健康检查筛选后的子集，而不是配置文件里写的原始地址列表。
- 不要把健康检查逻辑写在调度函数内部——开 goroutine 定期探测，结果缓存为
map[string]bool，调度时查表过滤 - 缓存过期时间建议设为 5–10 秒，太短增加探测压力，太长导致故障发现延迟
- 如果用
sync.Map存健康状态，注意Load返回的是interface{}，需类型断言
算法本身可以很简单，但脱离运行时上下文（健康状态、并发安全、权重收敛性）谈实现，等于在生产环境埋雷。
