gRPC客户端默认不支持负载均衡，需显式启用resolver与balancer协同机制：必须通过grpc.WithResolvers注册resolver、grpc.WithBalancerName指定策略（如"round_robin"），否则默认"pick_first"仅连首个地址。
gRPC客户端默认不支持负载均衡
Go 的 grpc.Dial 默认只连单个地址，即使你传入多个 endpoint（比如 "10.0.1.1:8080,10.0.1.2:8080"），它也不会自动分发请求——而是直接报错或只用第一个。gRPC 的负载均衡逻辑必须显式启用，且依赖 resolver + balancer 两套机制协同工作。
常见错误现象：rpc error: code = Unavailable desc = connection closed 或始终打到同一台后端，监控里流量完全不均。
- 必须通过
grpc.WithResolvers注册自定义 resolver，把服务发现结果喂给 gRPC - 必须指定
grpc.WithBalancerName（如"round_robin"），否则 balancer 不生效 - Go 标准库自带的
"round_robin"和"pick_first"是唯二开箱即用的策略；"pick_first"是默认值，本质是“只选第一个”，不是负载均衡 - resolver 返回的
address.Address列表，必须每个都带有效 IP+端口，不能含空字符串或非法格式，否则 balancer 会静默跳过
用 dns:// 或 passthrough:// 协议绕过自研 resolver
如果你后端是固定 IP 列表、DNS 可解析、或已由外部服务发现组件（如 Consul Agent）做了 SRV 记录，可以直接复用 gRPC 内置 resolver，避免写一堆 resolver.Builder 实现。
使用场景：K8s Service ClusterIP + Headless Service、CoreDNS 配合 SRV、本地开发多实例直连。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- DNS 解析：传
"dns:///my-service.default.svc.cluster.local:8080"（注意三个斜杠），gRPC 会定期查 A 记录并更新地址列表 - 透传模式：传
"passthrough:///10.0.1.1:8080,10.0.1.2:8080"，gRPC 把逗号分隔的地址直接转成address.Address，再交给 balancer - 务必配合
grpc.WithBalancerName("round_robin")，否则 passthrough 下仍是pick_first - DNS 模式下，gRPC 默认每 30 分钟刷新一次记录，可通过
grpc.WithResolvers(dns.NewBuilder())自定义刷新间隔，但别设太短（DNS 压力+连接抖动）
自定义 balancer 要重写 Pick 和 UpdateClientConnState
想实现加权轮询、最少连接数、或按 header 灰度路由？得自己写 balancer。但别从头造轮子——继承 base.Balancer 是最稳的起点，它帮你管好了 SubConn 生命周期和连接状态同步。
容易踩的坑：直接实现 balancer.Balancer 接口，漏掉 UpdateClientConnState 导致地址变更不生效，或在 Pick 里做阻塞操作拖垮整个 RPC 调用链。
-
Pick方法必须快速返回，不能查 DB、调 HTTP、或 sleep；建议只做内存级决策（比如查 map、atomic 计数器） -
UpdateClientConnState里拿到新地址列表后，要调用bc.ResolverState.Addresses对比旧列表，对新增地址调cc.NewSubConn，对删除地址调cc.RemoveSubConn - 所有 SubConn 必须通过
cc.NewSubConn创建，不能自己 new；连接状态变化（如 CONNECTING/READY）要通过sc.UpdateState上报 - 示例片段：
if state.ConnectivityState == connectivity.Ready { sc.UpdateState(balancer.SubConnState{ConnectivityState: connectivity.Ready}) }
etcd 或 nacos 做服务发现时，resolver 和 balancer 的协作边界
当后端注册在 etcd，客户端要拉取实例列表并实时感知上下线，resolver 负责“拉数据+监听变更”，balancer 负责“怎么用这些数据”。两者职责不能混：resolver 不决定路由逻辑，balancer 不负责 watch key。
性能影响：resolver 如果每次 watch 都全量重推地址列表（哪怕只变一个节点），会导致 balancer 频繁重建 SubConn，引发大量 TCP 连接震荡。
- resolver 的
ResolveNow应只触发一次主动查询，不重启 watch；watch 回调里用cc.UpdateState推增量变更 - balancer 收到新
ResolverState后，应 diff 地址差异，只增删对应 SubConn，而不是全量重建 - etcd clientv3 的
Watch返回的是WatchResponse，需解析Events类型（mvccpb.PUT/mvccpb.DELETE）来判断增删，别直接拿response.Kvs全量覆盖 - nacos 的
Subscribe回调里，serviceInstances是当前快照，resolver 需自己比对前后两次快照，生成差量事件再推给 balancer
真正难的不是写代码，是让 resolver 的推送节奏和 balancer 的 SubConn 管理节奏咬合住——差一点，连接就疯长或请求就失败。调试时盯紧 grpclog 输出的 subchannel 和 roundrobin 日志，比埋点还准。
