直接轮询服务列表会因节点临时不可达导致请求失败，需用sync.map实现带健康状态标记的回退机制，跳过近期失败节点并避免并发不安全。
为什么直接用 net/http 轮询服务列表会出问题
服务发现客户端如果只按固定顺序尝试节点，一旦首个节点临时不可达（如网络抖动、Pod 重启），整个请求就失败——这违背了“高可用”的基本预期。回退机制不是锦上添花，而是应对真实集群中节点健康状态动态变化的刚需。
关键点在于：回退 ≠ 简单重试，而是要跳过已知异常节点，尝试下一个候选，且不能无限遍历或阻塞主线程。
- 常见错误是把服务列表硬编码进循环，没做健康标记，每次请求都从头开始试，浪费资源
- 忽略并发安全：多个 goroutine 同时更新节点状态时，
map或切片可能 panic - 没区分临时性错误（连接超时）和永久性错误（404、503），导致不该跳过的节点被误判失效
用 sync.Map + 状态标记实现轻量级节点健康缓存
不需要引入完整熔断库（如 gobreaker），用标准库就能支撑大多数场景。核心是为每个服务实例维护一个最近是否可用的状态，并在失败后短暂标记为“退避中”。
示例逻辑：
// 假设 nodes = []string{"http://svc-1:8080", "http://svc-2:8080", ...}
var healthMap sync.Map // key: node URL, value: int64 (unix timestamp of last failure)
func selectNode() string {
now := time.Now().Unix()
for _, node := range nodes {
if lastFail, ok := healthMap.Load(node); ok {
if now-lastFail.(int64)
- 用
sync.Map避免锁竞争，适合读多写少的健康状态缓存 - 退避时间（如 30 秒）必须可配置，不能写死；短了压不住抖动，长了影响恢复速度
- 不要在
markFailed中清除旧状态——让自然过期更简单可靠
如何与 http.RoundTripper 结合实现透明回退
用户调用 http.Client.Do(req) 时，不希望感知底层节点切换。把回退逻辑下沉到 Transport 层，是最干净的解法。
关键改造点：
- 自定义
RoundTrip方法：先选节点 → 构造新*http.Request→ 发起请求 → 失败则标记并重试下一个 - 必须限制最大重试次数（建议 ≤ 3），否则可能把所有节点轮一遍还失败，反而延长延迟
- 对非网络类错误（如
401 Unauthorized）不应触发回退，否则会把鉴权失败扩散成服务不可用 - 注意重用
req.URL和req.Header，但每次都要新建req实例，避免 header 被复用污染
和服务注册中心（如 Consul/Etcd）联动时的坑
本地健康缓存只是第一层防御；当服务列表本身变更（如节点下线），你得及时刷新 nodes 切片，否则回退永远在旧集合里打转。
实操建议：
- 不要轮询拉取服务列表——用 Watch 机制（如
consul/api的BlockingQuery）监听变更 - Watch 回调里替换
nodes时，要用原子操作（如atomic.StorePointer指向新切片），避免遍历时切片被修改引发 panic - Watch 断连后需自动重连，但重连期间不能清空本地节点列表，否则造成雪崩式回退失败
- 如果注册中心返回的节点带权重或元数据（如
version=2.1），回退策略应优先选匹配版本的节点，而非简单顺序遍历
回退机制真正的复杂点不在选节点，而在于状态一致性：本地缓存、注册中心视图、实际网络可达性三者之间总有延迟。别试图完全消除它，而是用分层策略（快速本地退避 + 异步注册中心同步）把它控制在可接受范围内。
