grpc客户端默认不支持轮询或随机负载均衡，需显式启用round_robin或自定义balancer；必须通过dns:/// resolver获取多地址，且go 1.21+需配置serviceconfig。
gRPC客户端默认不支持轮询或随机负载均衡
Go 的 grpc.Dial 默认只做 DNS 解析 + 连接池复用，不会对多个后端地址做任何分发策略。你传入 []string{"10.0.1.1:8080", "10.0.1.2:8080"}，它只会选第一个连上，其余被忽略——这不是 bug，是设计如此。
真正起作用的是 resolver（解析器）+ balancer（负载均衡器）两层机制：resolver 负责把服务名转成地址列表，balancer 决定每次请求用哪个地址。Go 标准库自带的 passthrough resolver 和 pick_first balancer 就是“只用第一个”的原因。
- 要启用轮询（round_robin），必须显式注册并启用
round_robinbalancer，且 resolver 返回的地址列表不能为空 - Go 1.21+ 默认禁用
round_robin，需手动开启：grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`) - 如果用的是自定义 resolver（比如基于 etcd 或 nacos），确保它返回的
resolver.Address列表包含全部健康节点，且ServerName字段一致
用内置 round_robin 实现客户端轮询
这是最轻量、无需引入第三方库的方案，但有几个硬性前提：
- 后端地址必须通过 DNS 或
dns:///resolver 提供（例如dns:///my-service.default.svc.cluster.local），不能直接写 IP 列表 - 必须关闭
grpc.WithInsecure()（除非你配了 TLS 并信任证书），否则dnsresolver 不会加载 - Go 1.21+ 需显式设置 ServiceConfig，否则
round_robin不生效
示例关键代码：
conn, err := grpc.Dial(
"dns:///my-service.example.com",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`),
)
注意：dns:/// 前缀不能少，且你的 DNS 必须能返回多条 A 记录（如 Kubernetes Headless Service）。直接传 "10.0.1.1:8080,10.0.1.2:8080" 是无效的。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
自定义 balancer 实现随机选择（Random Picker）
标准库没提供 random balancer，但实现一个极简版只要 30 行左右。核心是继承 balancer.BaseBalancerBuilder，重写 Pick 方法返回随机索引。
- 别在
Pick里加锁或做耗时操作，gRPC 调用路径很敏感，随机取模即可 - 务必检查
subConns是否为空，空列表时返回balancer.PickResult{}, balancer.ErrNoSubConnAvailable - 注册时用唯一名称，比如
random_picker，然后在 ServiceConfig 里引用它
注册与使用示例：
balancer.Register(&randomPickerBuilder{})
conn, _ := grpc.Dial("example.com",
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"random_picker": {}}]}`),
)
这个 random_picker 名称必须和你 balancer.Register 时传入的 builder 的 Name() 严格一致，大小写敏感，拼错就回退到 pick_first。
为什么不用第三方库（如 grpc-go-contrib）？
像 grpc-go-contrib 里的 roundrobin 或 random balancer 确实开箱即用，但它们通常依赖老版本 gRPC API（如 balancer.V2 接口未完全适配 Go 1.22+ 的 context 取消逻辑），容易出现连接泄漏或 Pick 卡死。
- 如果你项目已稳定用
google.golang.org/grpc@v1.60.1+，建议手写简单 balancer，控制权在自己手里 - 避免混用多个 balancer 实现（比如同时注册
round_robin和自定义random_picker），gRPC 不保证调用顺序，可能触发未定义行为 - 真实生产环境要注意：balancer 只管“选哪个连接”，不负责健康探测。节点挂了，得靠
KeepaliveParams或外部探活机制及时剔除
balancer 的逻辑运行在每次 RPC 调用前，哪怕只是 ctx.Done() 已触发，Pick 仍可能被执行一次——这点在超时密集场景下容易引发误判。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
