不需要——gRPC客户端默认支持round_robin和pick_first策略，需配合resolver与balancer扩展点生效；HTTP客户端无内置负载均衡，须借助代理、第三方库或自定义实现服务发现与健康探测。
微服务间调用时，gRPC 客户端要不要自己实现负载均衡？
不需要——但得明确谁在做、怎么做。Go 原生 gRPC 客户端默认只支持 round_robin 和 pick_first 两种内置策略，且必须配合 resolver（解析器）和 balancer（负载均衡器）扩展点才能生效。直接硬编码轮询或随机选节点，等于绕过 gRPC 的连接管理机制，容易导致连接泄漏、健康状态不同步。
实操建议：
- 优先使用
grpc.WithBalancerName("round_robin")，并确保后端地址通过resolver.Builder动态提供（例如基于 Consul 或 DNS） - 若需自定义策略（如加权、最少连接），必须实现
balancer.Balancer接口，并注册到balancer.Register - 避免在业务层手动维护服务实例列表 + 随机取一个——这会跳过 gRPC 的重试、超时、健康检查等关键能力
http.Client 调用 REST 微服务时，如何做客户端负载均衡？
Go 标准库不提供内置负载均衡，http.Client 本身无服务发现或路由逻辑，必须靠外部组件或封装实现。常见错误是把多个 http.Client 实例对应不同后端，再在上层做 if-else 分发——这既难维护，又无法感知节点故障。
实操建议：
- 用
net/http/httputil.NewSingleHostReverseProxy封装为代理层，配合自定义Director实现简单轮询或一致性哈希 - 更推荐引入轻量库如
go-resty+ 自定义resty.RetryStrategy，再结合service discovery（如 etcd）动态更新resty.SetHostURL - 注意：HTTP Keep-Alive 连接池默认绑定到单个
URL.Host，若手动拼接不同后端地址，需确保复用同一http.Transport并启用MaxIdleConnsPerHost
服务注册中心（如 Nacos、Consul）返回的实例列表，怎么安全地喂给 Go 客户端？
不能直接把 IP:Port 列表塞进 grpc.DialContext 或 http.DefaultClient。gRPC 要求地址格式为 dns:///service-name 或 passthrough:///ip:port1,ip:port2，而 HTTP 客户端需要自己做健康探测与剔除。
