Go 里用 rand.Intn 做随机负载均衡，为什么每次请求都打到同一个后端？
因为没初始化随机种子，rand.Intn 默认复用同一个伪随机序列，所有 goroutine 拿到的“随机”数完全一致。
- 必须在程序启动时调一次
rand.Seed(time.Now().UnixNano())（Go 1.20+ 推荐直接用rand.New(rand.NewSource(time.Now().UnixNano()))避免全局状态） - 并发场景下，别用全局
rand.*函数，改用局部*rand.Rand实例，避免锁竞争 - 示例中常见错：在 handler 里反复调
rand.Seed，导致纳秒级时间戳重复，随机性坍塌
轮询（Round Robin）实现时，sync/atomic 和 mutex 怎么选？
轮询本质是共享一个递增索引，高并发下原子操作比互斥锁更轻量，但要注意边界处理。
- 用
atomic.AddUint64(&index, 1)然后取模，比mu.Lock()+ 自增快 3–5 倍（实测 QPS 提升明显） - 注意：
uint64虽然不会溢出，但取模前要转成int，否则%运算不支持 uint64 直接参与 - 如果后端列表可能动态变更，原子计数器无法自动适配长度变化，此时必须加锁或换用带版本号的环形结构
真实服务中，http.RoundTripper 里嵌入负载均衡逻辑容易漏掉什么？
很多人直接在 RoundTrip 方法里选节点、改 req.URL.Host，但忽略 Transport 层的连接复用和 TLS 复用机制。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 修改
req.URL.Host后，http.Transport会按新 Host 建立独立连接池，旧连接不会复用——导致空闲连接堆积、TIME_WAIT 暴增 - 正确做法：用
req.Header.Set("Host", ...)保持 URL.Host 不变，仅透传目标 host 到后端（需后端支持 Host 头路由） - 若必须改 Host，记得给 Transport 配置
MaxIdleConnsPerHost，否则默认 2 个连接根本不够用
为什么简单轮询 / 随机在故障转移时经常失效？
因为这两种算法本身不感知后端健康状态，节点挂了还继续发请求，错误率直线上升。
立即学习“go语言免费学习笔记（深入）”；
- 最简补救：加一层本地健康检查缓存，用
sync.Map存 host → lastSuccessTime，超时（如 30s）未成功就跳过该节点 - 不要在每次请求时同步做 HTTP 探活——延迟爆炸；异步心跳 + 快速失败才是正解
- 轮询索引遇到不可用节点时，不能简单
i++，得循环找下一个可用项，否则可能死循环（尤其只剩一个节点且它也挂了）
