minconn 不是标准库内置策略，因为 net/http 和 httputil 不维护连接数状态，reverseproxy 默认无状态转发；需用原子计数器在请求前后增减，并在 selectminconnbackend 中先比较后原子加一以避免竞态。
为什么 minconn 不是标准库内置策略
Go 的 net/http 和 http/httputil 都不提供连接数感知的负载均衡逻辑，因为「当前活跃连接数」必须由代理层主动维护和更新，而 Go 标准库的 ReverseProxy 默认只做无状态转发。你得自己记录每个后端的并发请求数，并在每次 Director 调用时选最小的那个——否则就只是轮询或随机。
如何安全地统计每个后端的实时连接数
不能用全局变量加普通 int，高并发下会竞争；也不能用 sync.Mutex 包裹整个选择逻辑，否则成为性能瓶颈。正确做法是为每个后端配一个原子计数器，在请求开始前 +1、结束后 -1。
- 用
sync/atomic.Int64（Go 1.19+）或atomic.AddInt64（旧版）管理每个后端的连接数 - 在
ReverseProxy.Transport.RoundTrip后手动减计数——但更稳妥的是用http.Handler包裹后端调用，在defer中减 - 避免在
Director中直接读写计数器后立刻发请求，要防止「读到 0 → 发起请求 → 还没 +1 就被另一个 goroutine 读到 0」的竞态，所以 +1 必须在真正拨出请求前完成
怎么写一个线程安全的 selectMinConnBackend 函数
这个函数不是选「当前最小」就完事，它得确保返回的后端在返回瞬间确实是可用且计数最低的——中间不能有窗口期。常见错误是先找最小值再 +1，这会导致多个 goroutine 同时选中同一个后端并重复 +1。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
// 假设 backends = []string{"http://a:8080", "http://b:8080"}
// counters = map[string]*atomic.Int64{}
func selectMinConnBackend() string {
var minAddr string
var minVal int64 = math.MaxInt64
for _, addr := range backends {
v := counters[addr].Load()
if v
<p>注意：<code>CompareAndSwap</code> 失败说明计数已变，必须递归重选，否则可能漏掉真正更空闲的节点。</p>
<h3>实际集成到 <code>ReverseProxy</code> 时容易漏掉什么</h3>
<p>很多人只改了 <code>Director</code>，却忘了：HTTP/2 连接复用会让单个连接承载多个请求，此时「连接数」和「请求数」不等价；而 <code>minconn</code> 真正关心的是后端处理压力，所以应该按「并发处理中的请求」计数，不是底层 TCP 连接数。</p>
- 务必在
Director中调用selectMinConnBackend并设置req.URL.Host和req.URL.Scheme - 必须在
ReverseProxy.Transport的RoundTrip返回后（或http.Error发生时）及时-1，建议用中间件式包装器统一处理 - 初始时所有计数器应为 0，但要考虑后端宕机场景：对连续失败的后端，应临时屏蔽（比如加个
unhealthyUntil time.Time字段），否则会被误选
最常被跳过的细节是：没有把计数器的增减和请求生命周期严格绑定——比如 panic 未被捕获，defer 不执行，导致计数卡死。要用 recover() 或 context 超时兜底。
