gin 本身不提供负载均衡，需依赖上游网关、grpc 客户端（如启用 round_robin 并配置 dns:///target）、http 反向代理（自定义 host 选择）或 go-micro 框架；关键要确保服务发现返回多实例且实现健康检查闭环。
Gin 本身不提供负载均衡能力，它只是 HTTP 路由层；真正做负载均衡的必须是上游网关、客户端 SDK 或底层通信协议（如 gRPC）。 直接在 Gin handler 里写轮询逻辑是反模式，既难维护又易出错。
gRPC 客户端启用 round_robin 需要显式传入多个 target
如果你用 Gin 做 API 网关，并通过 gRPC 调用后端微服务，负载均衡实际发生在 grpc.ClientConn 层。默认 pick_first 只连第一个地址，必须手动切换策略并确保 DNS 解析返回多个 IP：
- target 格式必须是
"dns:///user-svc:8080"（注意三个斜杠和前缀dns://），不能是"user-svc:8080" - 需调用
grpc.WithBalancerName(roundrobin.Name)显式启用round_robin - Consul 或 Nacos 注册的服务名，要能被本地
getaddrinfo解析为多个 A 记录，否则 round_robin 无节点可选 - 若用
dns:///却只解析出一个 IP，gRPC 会退化为单点连接，且不报错
HTTP 场景下用 httputil.NewSingleHostReverseProxy 做简易 LB
当后端是 HTTP 服务（比如多个用户服务实例），Gin 可充当轻量网关，用标准库 net/http/httputil 转发请求。但注意：NewSingleHostReverseProxy 本身只支持单 host，需自己包装选择逻辑：
- 维护一个服务实例列表（如从 Consul 获取的
[]string{"http://10.0.1.10:8080", "http://10.0.1.11:8080"}） - 每次请求时调用自定义函数选 host（如取模或随机），再用该 host 构造新
*httputil.ReverseProxy - 务必设置
Director函数重写req.URL.Host和req.URL.Scheme，否则后端收不到正确 Host 头 - 不加
Transport自定义会导致连接复用失效，容易打满文件描述符
Go-Micro 客户端集成 Gin 时负载均衡由框架自动接管
如果你用的是已停更但仍在维护的 Go-Micro v2（github.com/micro/go-micro/v2），它的 client.Call 默认启用 round_robin，前提是注册中心返回了多个 service node：
- 初始化 client 时无需额外配置，但必须传入正确的
micro.Service实例（含注册中心配置） - 调用
client.Call()时，method 名需与服务端注册的 handler 名完全一致（大小写敏感） - 错误日志里出现
"no valid nodes found"，大概率是服务未正确注册，或注册中心地址填错（如 Consul 的host:port不通） - 别直接 new client 每次都创建，应复用全局 client 实例，否则 Balancer 状态丢失，退化为随机选择
真正容易被忽略的是健康检查闭环：无论用哪种方式做负载均衡，如果后端实例挂了却没及时剔除，流量仍会打过去。gRPC 的 round_robin 依赖底层连接状态自动摘机，而 HTTP 反向代理需要你自己加主动探测（如定期 HEAD 请求）+ 缓存标记。没有这个，再“均衡”的算法也只是一厢情愿。
