不需要——gRPC客户端默认支持round_robin和pick_first策略，需配合resolver与balancer扩展点生效；HTTP客户端无内置负载均衡，须借助代理、第三方库或自定义实现服务发现与健康探测。
微服务间调用时，gRPC 客户端要不要自己实现负载均衡？
不需要——但得明确谁在做、怎么做。Go 原生 gRPC 客户端默认只支持 round_robin 和 pick_first 两种内置策略，且必须配合 resolver（解析器）和 balancer（负载均衡器）扩展点才能生效。直接硬编码轮询或随机选节点，等于绕过 gRPC 的连接管理机制，容易导致连接泄漏、健康状态不同步。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先使用
grpc.WithBalancerName("round_robin")，并确保后端地址通过resolver.Builder动态提供（例如基于 Consul 或 DNS） - 若需自定义策略（如加权、最少连接），必须实现
balancer.Balancer接口，并注册到balancer.Register - 避免在业务层手动维护服务实例列表 + 随机取一个——这会跳过 gRPC 的重试、超时、健康检查等关键能力
http.Client 调用 REST 微服务时，如何做客户端负载均衡？
Go 标准库不提供内置负载均衡，http.Client 本身无服务发现或路由逻辑，必须靠外部组件或封装实现。常见错误是把多个 http.Client 实例对应不同后端，再在上层做 if-else 分发——这既难维护，又无法感知节点故障。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
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 客户端需要自己做健康探测与剔除。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对 gRPC：实现
resolver.Builder，监听注册中心变更，调用cc.UpdateState()推送新地址；同时搭配watcher做心跳检测，主动移除失联节点 - 对 HTTP：用
sync.Map缓存实例列表，配合后台 goroutine 定期http.Head探活，失败则标记unhealthy并降权（如跳过本次选择） - 关键细节：所有变更必须线程安全；gRPC 的
resolver更新不可阻塞，否则影响连接建立；HTTP 探活超时建议 ≤ 500ms，避免拖慢主调用
为什么本地启多个 Go 微服务实例，用 localhost:8001、localhost:8002 测试时负载不均？
因为绝大多数“本地测试”场景下，你没启用任何负载均衡逻辑——http.Get("http://localhost:8001/xxx") 永远只打第一个端口；grpc.Dial("localhost:8001") 也只连固定地址。这不是负载均衡失效，而是根本没开启。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 快速验证：改用
grpc.Dial("dns:///my-service", grpc.WithBalancerName("round_robin"))，再启动一个自定义resolver返回两个本地地址 - HTTP 侧可临时用
gorilla/handlers.ProxyHeaders+httputil.NewMultiHostReverseProxy，把请求分发到多个localhost端口 - 最容易被忽略的一点：本地 hosts 或 DNS 解析可能缓存了旧地址，改完注册中心配置后要清空
dig my-service或nslookup缓存，否则看到的仍是单点流量
