动态负载均衡在Go中必须满足节点热更新、健康感知、权重变更不中断三条件；atomic轮询需配合健康快照取模，加权轮询须用SWRR算法，权重变更需版本号或位封装保障原子性。
动态负载均衡在 Go 模块中不是加个 rand.Intn() 或维护一个全局 index 就能“跑起来”的事——它必须同时满足三个硬性条件：节点列表可热更新、健康状态可感知、权重变更不中断服务。做不到这三点，所谓“动态”只是假象。
为什么直接用 atomic.AddUint64(&idx, 1) 做轮询会出问题
看似线程安全，但实际埋了两个雷：
- 节点列表在运行时增删（比如服务注册/下线），而
idx仍按旧长度取模，导致越界 panic 或跳过新节点 - 没过滤不健康节点，请求照发，失败率陡升；若 fallback 到下一个索引，又可能形成“连续打挂多个节点”的雪崩链
正确做法是每次 Select() 前先获取一份**健康节点快照**（深拷贝或读锁保护的 slice），再对快照做原子索引取模。快照长度必须实时参与计算，不能缓存。
加权轮询必须用 SWRR，别碰 rand.Float64() 归一化
用随机数落区间（如权重 [3,1,2] → 落点 [0,0.5)）短期分布极不稳定，且无法响应运行时调权——你刚把 node.weight 从 3 改成 1，已有 goroutine 还在用旧 weight 算区间。
立即学习“go语言免费学习笔记（深入）”；
平滑加权轮询（SWRR）才是工业级解法：
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 每个节点结构体带
weight int64和current int64字段 - 选择时遍历所有节点，用
atomic.LoadInt64(&node.current)找最大值对应节点 - 选中后执行
atomic.AddInt64(&node.current, -1)，若current降为 0，则atomic.StoreInt64(&node.current, node.weight)
注意：current 重置必须在扣减后判断，且不能和其他节点的重置操作竞争——否则高并发下会漏重置。
如何让权重变更真正“动态”，而不是 reload 配置
直接写 node.weight = newWeight 是错的。此时若有 goroutine 正在执行 atomic.AddInt64(&node.current, -1)，它刚读完旧 weight 就被你改了值，后续重置时就会用错 weight。
安全方案只有两种：
- 引入版本号：
version uint64，每次调权时atomic.AddUint64(&node.version, 1)；选择逻辑中，扣减后重置前校验 version 是否变化，变了就放弃本次重置 - 更轻量：把
weight和current合并进一个int64，高 32 位存 weight，低 32 位存 current，用atomic.CompareAndSwapInt64原子更新——但要注意 low32 溢出时需回绕处理
健康检查不能每次请求都探活
在 Select() 里直接发起 HTTP / TCP 探针？那吞吐量直接归零。真实做法是：
- 健康检查异步运行（比如每 5 秒一次），结果缓存在节点结构体的
healthy bool字段 +lastCheckTime time.Time -
Select()只读这个缓存字段，TTL 过期（如 30 秒）则视为未知状态，但默认按不健康处理 - 空健康列表必须显式返回
ErrNoAvailableNode，不能静默 fallback 或 panic
最易被忽略的一点：健康检查缓存和节点列表快照必须是同一时刻的视图。如果快照取的是 11:45:01 的列表，而健康状态是 11:45:03 更新的，中间的窗口期会导致误判——需要用 sync.RWMutex 或 atomic.Value 统一封装整个节点池状态。
