轮询策略需用原子操作维护索引并基于健康节点快照取模，避免竞态与越界；随机策略须用独立rand.rand实例防倾斜；负载均衡必须集成健康检查与动态节点更新机制。
轮询策略怎么写才不会丢请求
轮询（Round Robin）不是简单维护一个全局计数器加一取模——并发下会竞态，sync/atomic 或 sync.Mutex 必须介入。更稳妥的做法是用原子操作维护索引：atomic.AddUint64(&idx, 1) 再对节点数取模，避免锁开销。
常见错误是把节点列表做成固定切片但运行时动态增删，导致索引越界或漏节点。正确做法是每次获取节点前先读一次当前节点列表快照（深拷贝或加读锁），再基于快照做取模。
- 节点为空时必须提前返回错误，不能静默 panic 或返回 nil
- 如果节点带权重，别用简单取模，改用加权轮询（如平滑加权轮询 SWRR），否则高权重节点可能被连续选中多次
- 注意 Go 的
uint64溢出：长期运行后atomic.AddUint64可能绕回 0，但取模本身不受影响，无需额外防护
随机策略为什么比看起来更难控制
直接用 rand.Intn(len(nodes)) 看似简单，但默认的 rand 是全局共享、非线程安全的，且未设置 seed 会导致每次启动都生成相同序列——测试时看似稳定，上线后却出现流量倾斜。
真正可用的随机分发必须满足两点：每个 goroutine 持有独立 *rand.Rand 实例（用 rand.New(rand.NewSource(time.Now().UnixNano())) 初始化），或使用 rand.Intn 前加锁（性能差，不推荐）。
- 不要在 init 函数里调用
rand.Seed()：Go 1.20+ 已弃用，且无法解决并发问题 - 如果要求「同一请求 ID 总落到同一节点」（比如 sticky session），随机就不适用，得换一致性哈希
- 纯随机在节点数少、请求数少时容易出现明显不均，建议节点数 ≥ 3 且 QPS ≥ 100 再考虑
如何让轮询和随机支持健康检查切换
负载均衡器不能只看算法，还得感知节点是否存活。硬编码的轮询/随机逻辑一旦遇上宕机节点，就会持续转发失败请求。
关键是在选择节点前插入过滤步骤：遍历节点列表，调用 node.IsHealthy()（可基于最近心跳、HTTP 探针或熔断状态），只在健康节点子集中执行轮询或随机。
- 健康检查结果必须缓存（比如 TTL 30 秒），避免每次请求都发起探针
- 过滤后的健康节点数为 0 时，不能 fallback 到不健康节点，应直接返回
ErrNoAvailableNode - 轮询索引要基于健康节点列表长度重新映射，而不是原始列表长度，否则索引会错位
gorilla/handlers 和 net/http.RoundTripper 怎么配合用
如果你在 HTTP 代理场景用轮询/随机，别自己重写整个 http.Handler；优先复用标准库能力。例如用 net/http.RoundTripper 封装负载逻辑，再注入到 http.Client 中，比拦截 http.ServeHTTP 更轻量、更符合 Go 的组合习惯。
典型结构是定义一个 LBTransport 类型，实现 RoundTrip(*http.Request) (*http.Response, error) 方法，在其中调用轮询/随机选节点，拼接目标 URL，再用底层 &http.Transport{} 发起真实请求。
- 注意
Request.URL要 deep-copy 并修改Host和Scheme，否则可能被中间件覆盖 - 别在
RoundTrip里做重试：它只负责单次转发，重试应由上层http.Client控制 - 如果用了
gorilla/handlers.CompressHandler这类中间件，确保 LB 逻辑在压缩之前执行，否则响应体可能已被缓冲
最易被忽略的是节点变更通知机制：配置热更新、服务发现变化时，轮询索引和健康缓存必须同步重置，否则会继续往已下线节点发请求。这比算法本身更难测、更容易在线上静默出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
