gin的/health端点仅实现进程存活探测，无法替代负载反馈，因其不检查下游依赖、不暴露实时指标、不支持状态持久化与多维决策。
Gin 本身不提供负载反馈机制 —— 它只是 HTTP 路由层，没有内置的健康指标采集、请求成功率统计或自动权重调整能力。所谓“负载反馈”，实际是靠外部组件协同完成的：服务注册中心（如 Consul）做健康检查，客户端（如 go-micro 或自定义 http.RoundTripper）感知状态变化，再配合策略选节点。Gin 在其中只负责暴露 /health 端点或转发调用，不能主动“反馈”负载。
为什么 Gin 的 /health 端点不能替代负载反馈
很多团队在 Gin 中加一个 GET /health 路由，返回 {"status": "ok"}，就以为实现了负载反馈。这其实只解决了最表层的存活探测，漏掉了关键维度：
- 它不反映后端依赖（如数据库、下游 gRPC 服务）是否可用 —— 单纯 Gin 进程活着，不代表整个服务可服务
- 它不暴露实时指标（如当前 goroutine 数、pending 请求量、平均延迟），注册中心无法据此做加权或剔除
- Consul/Etcd 的默认 HTTP 检查只会看 HTTP 状态码，不会解析响应体内容，
200 OK就算通过，哪怕 DB 连接池已耗尽
真正有用的健康端点得聚合下游状态，比如用 github.com/sony/gobreaker 包裹 DB 调用，失败率超阈值时主动返回 503 Service Unavailable。
gRPC 客户端调用时如何让负载均衡器“感知”失败
当 Gin 作为 API 网关调用后端 gRPC 服务时，如果某实例连续返回 UNAVAILABLE 或超时，你希望 round_robin 自动跳过它 —— 但默认不会。原因和解决方式如下：
-
grpc-go的round_robin是连接粒度的，不是请求粒度；一次连接建立后，后续请求仍会打到该连接对应实例，直到连接断开 - 必须启用连接级健康检查：在 Dial 时加
grpc.WithKeepaliveParams(keepalive.ClientParameters{Time: 10 * time.Second})，并确保后端启用了health.CheckService - 更可靠的做法是用
go-micro/v2的selector：它会在每次Call()前拉取 registry 中的健康实例列表，天然规避已标记为critical的节点 - 别依赖
grpc.WithBalancerName("round_robin")在老版本（如 v1.47）中生效 —— v1.60+ 才默认启用，且只对dns:///地址有效
用 http.RoundTripper 实现带反馈的轮询时的关键陷阱
有些团队自己写 RoundTripper，在 Transport 层做实例轮转。这看似灵活，但极易踩坑：
- DNS 缓存未禁用：
net/http默认复用 DNS 解析结果，K8s 中 Pod IP 变更后，旧连接仍发往已销毁的 IP —— 必须设Transport.DialContext配合自定义net.Resolver，或直接用http.DefaultClient.Transport.(*http.Transport).MaxIdleConnsPerHost = 0强制每次新建连接 - 健康状态未持久化：轮询逻辑里记录了某实例连续失败 3 次，但进程重启就清零 —— 应把临时状态存在内存 map + TTL，或写入本地文件（简单场景）
- 没处理重试与幂等：轮询到失败节点后直接切下一个，但原请求可能已在下游执行成功（如支付接口），此时重试会引发重复扣款 —— 必须在业务层加幂等 key，不能全交给 Transport 层
- 忽略 TLS 握手开销：每个新实例都重建 TLS 连接，高并发下 CPU 和证书验证成为瓶颈 —— 应复用
http.Transport并配置MaxIdleConns和IdleConnTimeout
真正难的不是轮着发请求，而是让轮询决策能基于真实、及时、多维的服务状态 —— 这需要 Consul 的 TTL 检查、gRPC 的 health service、应用层埋点指标三者对齐，Gin 只是链路末端那个暴露接口的“窗口”。
