go标准库无加权最小连接数实现，需用sync.map存节点、atomic.int64维护activeconn以保障并发安全；难点在于权重与动态连接数的原子更新及低延迟读取。
Go 标准库不提供加权最小连接数（Weighted Least Connections）的现成实现，必须自己组合 sync.Map、原子计数器和权重调度逻辑——核心难点不在算法本身，而在并发安全地维护连接数与权重的动态平衡。
为什么不能直接用 roundrobin 或 leastconn 包？
社区常见负载均衡库（如 golang.org/x/net/http/httpproxy 或第三方 lb 包）只支持轮询、随机或简单最小连接，不支持「权重 × 当前活跃连接数」的复合评分。加权最小连接要求每个后端节点同时携带两个状态：weight（静态配置）和 activeConn（运行时动态变化），且更新必须原子、读取需低延迟。
- 用
map[string]int存连接数 → 并发写 panic - 用
sync.Mutex全局锁 → 高并发下成为瓶颈，Get()变慢 - 把权重硬编码进结构体但不校验合理性（比如权重为 0 或负数）→ 调度结果不可控
如何用 sync.Map + atomic.Int64 安全维护节点状态？
每个后端节点抽象为一个结构体，其中 activeConn 必须用 atomic.Int64，避免锁；weight 可用普通字段（只读）；整个节点集合用 sync.Map 管理，键为节点地址（如 "10.0.1.5:8080"）。
示例关键片段：
type Backend struct {
addr string
weight int64
activeConn atomic.Int64
}
func (b *Backend) Inc() int64 { return b.activeConn.Add(1) }
func (b *Backend) Dec() int64 { return b.activeConn.Add(-1) }
func (b *Backend) GetConn() int64 { return b.activeConn.Load() }
// 加权评分：score = activeConn / weight（注意 weight > 0）
func (b *Backend) score() float64 {
if b.weight
- 不要在
score()中做除零保护以外的浮点运算（比如math.Max），影响性能 -
sync.Map的LoadOrStore用于懒初始化节点，避免预热时创建空节点 - 权重变更应触发重新排序缓存（如有），但运行中不建议频繁改权重
选择节点时怎么避免 ABA 问题和短暂不一致？
获取最小 score 节点时，不能先遍历找最小值再 Inc() —— 这中间可能被其他 goroutine 修改。必须「原子读-比较-写」，即先拿到候选节点指针，再用 Inc() 并验证该节点仍是当前最小（可选二次检查）。
- 推荐做法：遍历所有节点，用
score()计算当前值，记录最小 score 对应的*Backend指针；然后调用其Inc()，返回该节点 - 不推荐：用
atomic.CompareAndSwap模拟 CAS 更新 score —— score 是派生值，无法直接 CAS - 如果节点列表很大（>100），考虑加本地缓存（如 LRU）+ 定期刷新，但会引入 stale risk
- HTTP 场景下，务必在
RoundTrip结束后调用对应节点的Dec()，哪怕发生错误也要 defer 执行
真正难的不是算分，是让 Inc()/Dec() 和节点选择逻辑在高 QPS 下保持低延迟且不出错。权重设得过大或过小都会放大抖动——比如权重比为 100:1，小权重节点几乎永远不会被选中，除非大权重节点挂掉。实际部署前，一定要用真实连接生命周期模拟压测，而不是只看 CPU 占用。
