go中failover的核心是“一成功即停止，其余自动取消”，需用select监听首个完成结果、每个请求配独立context.withtimeout、缓冲chan接收结果、http层传context中断阻塞操作，并注意错误分类、body关闭和节点过滤。
Go 中用 select + context.WithTimeout 实现请求 Failover
Failover 的核心不是“多发几个请求”，而是“只要一个成功就停手，其余自动取消”。Go 里最自然的做法是启动多个 goroutine 并发请求，靠 select 监听第一个完成的 chan，同时用 context 让失败或超时的请求主动退出，避免资源堆积。
常见错误是只起 goroutine 却不 cancel 其他请求，导致备用节点还在跑、连接没关、内存泄漏。比如用 http.Client 发请求时，没传带 cancel 的 context，即使主流程已返回，底层 TCP 连接和 goroutine 仍可能卡住数秒。
- 每个请求必须使用独立的
context.WithTimeout（不要复用同一个ctx），否则一个 cancel 会误杀全部 - 推荐用
make(chan result, 1)（缓冲为 1）接收结果，避免 goroutine 永久阻塞在发送上 - 所有请求路径、Header、Body 必须完全一致，否则服务端行为可能不同，Failover 变成“随机选一个错的”
为什么不能只靠 time.After 或 time.Sleep 控制超时
time.After 看似简单，但它只解决“等多久”，不解决“怎么让正在跑的 HTTP 请求停下来”。HTTP 请求一旦发出，time.After 到期后你只能干等它自己结束——而它可能卡在 DNS 解析、TCP 握手、TLS 协商或服务端慢响应上，根本不受你控制。
真正可控的超时必须下沉到 HTTP 层：把 context.Context 传给 http.NewRequestWithContext，再交给 http.Client.Do。Client 内部会监听 context Done，并在触发时关闭底层连接。
立即学习“go语言免费学习笔记（深入）”；
-
http.Client.Timeout是整个请求生命周期上限，但无法中断正在进行的阻塞操作（如 TLS 握手）；context才是唯一能打断它的机制 - 别在 goroutine 里用
time.Sleep模拟延迟备用——这会让 Failover 变成串行，失去并发意义 - 如果服务端支持，可考虑用
http.Header加X-Request-Id和X-Failover-Attempt方便后端日志对齐
备用节点地址怎么传？用切片还是 channel？
传地址列表最安全的方式是函数参数传 []string，而不是通过全局变量或闭包捕获。因为 Failover 场景下节点可能动态变化（比如配置热更新），而 goroutine 启动后闭包捕获的变量不会自动刷新。
切片足够用：长度通常 ≤3，遍历开 goroutine 开销极小；用 channel 反而增加复杂度，还要额外管理发送/关闭逻辑，且无法保证顺序或重试轮转策略。
- 节点顺序有业务含义（比如优先本地机房），所以别用
rand.Shuffle随机打乱，除非明确需要负载分散 - 如果某节点连续失败，应在调用前过滤掉（比如查缓存中的熔断状态），否则每次 Failover 都会固定卡在坏节点上
- 注意 DNS 缓存：
http.DefaultClient默认复用连接，若备用域名解析失败，得清空http.Transport.DialContext或换新http.Client
错误处理时容易漏掉的三个点
Failover 不是“有返回就完事”，错误分类直接影响重试决策。比如 context.DeadlineExceeded 是超时，可以走下一个节点；但 net.OpError 中的 timeout: i/o timeout 是底层 IO 超时，说明网络或服务端已不可达，继续试其他节点也大概率失败。
另一个坑是忽略 http.Response.Body 关闭：哪怕只读了 status code，也得 resp.Body.Close()，否则连接不会归还给连接池，高并发下很快耗尽 MaxIdleConns。
- 检查
err != nil后，别直接 return，先看是不是errors.Is(err, context.Canceled)或context.DeadlineExceeded——前者是被主动取消（正常），后者才是真超时（该 Failover） - 如果所有节点都返回
503 Service Unavailable，应统一转成自定义错误（如ErrAllNodesUnavailable），方便上层区分“全挂了”和“单点故障” - 别在 defer 里关
Body：goroutine 里 defer 的执行时机不可控，可能 body 还没读完就关了；应紧挨着io.ReadAll或json.NewDecoder后立刻Close()
Failover 看似只是“多发几个请求”，但 Go 里真正难的是让每个请求干净退出、错误精准归因、连接不泄漏——这些细节不抠清楚，压测时 CPU 和 goroutine 数会悄无声息地涨上去。
