不能直接用RoundRobin结构体做负载均衡，因其index字段在并发下竞态，且无健康检查机制；必须用sync.RWMutex或atomic保护索引，并配合独立goroutine周期探活、atomic.Value动态更新节点列表。
为什么不能直接用 RoundRobin 结构体做负载均衡
直接暴露 RoundRobin 这类带 index 字段的结构体，会在并发场景下产生竞态：多个 goroutine 同时调用 Next() 会覆盖彼此的 index 值，导致跳过节点或重复调度。更严重的是，它完全不感知后端是否存活——哪怕某个 endpoints 已经 http://10.0.1.10:8080 返回 503 或超时，依然会被选中。
- 必须用
sync.RWMutex或atomic.Int64保护索引递增逻辑 - 健康状态不能靠“调用时再探测”，得有独立 goroutine 周期性探活（如每 10s 调一次
/health） - 节点列表更新不能直接赋值
t.endpoints = newEndpoints，否则正在执行的RoundTrip可能 panic
如何让 LoadBalanceTransport 支持运行时 endpoint 更新
硬编码 endpoints []string 字段会导致每次增删节点都要重启服务。正确做法是用 atomic.Value 封装可变列表，配合 sync.Map 存储每个节点的健康状态（key 是 host:port，value 是 bool）。
- 写入新 endpoints 时：先构造新切片，再调用
atomic.StorePointer替换旧指针 - 读取时：用
atomic.LoadPointer获取当前切片地址，再转成[]string - 别在
RoundTrip里调sync.Map.Load—— 它不是无锁的，高并发下会拖慢请求；应提前过滤出健康节点子集再轮询
为什么 httputil.NewSingleHostReverseProxy 不适合直接复用
直接拿 httputil.NewSingleHostReverseProxy(u) 在每次 RoundTrip 里创建新实例，会泄漏连接池和 goroutine。它的 Director 函数只改 req.URL，但没处理 Host 头、Path 拼接、RawQuery 清空等细节，容易导致请求发到错误路径（比如 /api/v1/user 变成 //api/v1/user）。
- 应该只初始化一次
*httputil.ReverseProxy实例，复用其Transport字段 - 必须手动设置
req.Host = u.Host、req.URL.Scheme = u.Scheme、req.URL.Host = u.Host -
req.URL.Path和req.URL.RawQuery必须置空，否则会与原始路径二次拼接 - 若需保留原始
Host头给后端鉴权，得用req.Header.Set("X-Forwarded-Host", req.Host)显式透传
加权轮询和最少连接数怎么接入现有 RoundTripper
把算法从调度逻辑里解耦出来，定义统一接口：type Balancer interface { Select(healthy []string) string }。这样轮询、加权轮询、最少连接数就能互换，而不用重写整个 RoundTrip 方法。
立即学习“go语言免费学习笔记（深入）”；
- 加权轮询实现要维护每个节点的
currentWeight和maxWeight，每次选完后递减，归零时重置为原始权重 - 最少连接数需要额外字段记录每个节点当前活跃连接数，用
http.Transport.MaxIdleConnsPerHost控制上限，避免误判 - 所有算法返回前必须检查节点是否在健康列表里，否则可能选中刚下线但状态未同步的节点
Select 阶段做双重校验，而不是依赖“检查完就等于可用”。 
