gRPC客户端连接复用需手动全局复用单个*grpc.ClientConn实例，禁用每次请求的defer conn.Close()，配合grpc.WithBlock()、grpc.WithKeepaliveParams及显式负载均衡策略（如round_robin）实现高效长连接。
gRPC客户端连接复用必须手动控制 grpc.Dial
Go 默认不会自动复用 gRPC 连接，每次调用 grpc.Dial 都新建底层 TCP 连接，哪怕目标地址完全一样。这直接导致连接数爆炸、TLS 握手开销大、DNS 重查频繁。
正确做法是全局复用一个 *grpc.ClientConn 实例，直到服务生命周期结束：
// ✅ 正确：一次 Dial，长期复用
var conn *grpc.ClientConn
func init() {
var err error
conn, err = grpc.Dial("127.0.0.1:8080",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithBlock(), // 避免后台异步连接失败后静默降级
)
if err != nil {
log.Fatal(err)
}
}
// 后续所有 stub 创建都用这个 conn
client := pb.NewUserServiceClient(conn)
-
grpc.WithBlock()很关键：避免grpc.Dial立即返回未就绪的连接，导致首次 RPC 超时或失败 - 别在每次请求里
defer conn.Close()—— 这会把连接池直接干掉 - 如果服务端地址动态变化（如通过 DNS 或服务发现），需配合
grpc.WithResolvers+ 自定义 resolver，而非反复 Dial
连接池不是内置概念，得靠 grpc.WithTransportCredentials 和底层 HTTP/2 设置
gRPC Go 没有“连接池”抽象层，连接复用实际由 HTTP/2 的 http2.Transport 控制。默认配置下，单个 *grpc.ClientConn 内部已支持多路复用和连接保活，但容易被误关。
- 确保不设置
grpc.WithTimeout在grpc.Dial里 —— 它影响的是 Dial 阶段，不是后续 RPC - 需要长连接保持活跃，加
grpc.WithKeepaliveParams：
grpc.WithKeepaliveParams(keepalive.ClientParameters{
Time: 30 * time.Second,
Timeout: 10 * time.Second,
PermitWithoutStream: true,
})
-
PermitWithoutStream必须设为true，否则空闲时无流就不会发 keepalive ping，连接可能被中间设备（NAT、LB）悄悄断开 - HTTP/2 的最大流数（
MaxConcurrentStreams）由服务端控制，客户端无法绕过；但客户端可通过并发调用自然触发多路复用，无需手动“建多个连接”来提升吞吐
负载均衡必须显式启用，且只在 grpc.Dial 时生效
gRPC Go 默认是「无负载均衡」：所有请求打到第一个解析出的地址（比如 DNS 返回的第一个 IP）。要实现轮询或其它策略，必须开启内置 LB 策略并配合合理的 name resolver。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 使用
dns:///example.com:8080这类带 scheme 的 target，并启用grpc.WithDefaultServiceConfig：
conn, _ := grpc.Dial("dns:///my-service.example.com:8080",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy": "round_robin"}`),
)
- 注意：
round_robin是唯一稳定可用的内置策略；grpclb已弃用，pick_first是默认行为（即不均衡） - DNS 解析结果变更（如扩缩容）不会自动热更新 —— 需要
grpc.WithWatchers或自己实现定时重解析，否则连接会一直卡在旧地址池 - 若用 Consul/Etcd 等注册中心，必须写自定义 resolver，不能只靠 DNS + round_robin
健康检查与连接故障恢复常被忽略，grpc.FailFast 是双刃剑
默认情况下，gRPC 客户端对失败请求立即报错（FailFast = true），不尝试重试或换节点。这在服务瞬时抖动时放大错误率，但设成 false 又可能阻塞太久。
- 对非幂等操作（如
CreateUser），保持FailFast = true更安全；对查询类操作，建议关闭：
client.GetUser(ctx, &req,
grpc.WaitForReady(true), // 等待连接就绪，替代 FailFast=false 的模糊语义
)
-
grpc.WaitForReady(true)比FailFast = false更明确：它会让 RPC 等待连接恢复（比如断连重连中），而不是盲目重试或失败 - 没有内置的「自动重连」机制 ——
conn.ReadyState()可查状态，但重建连接 + 重试逻辑得自己兜底 - 真实生产环境里，连接中断往往伴随 DNS 失效、证书过期、服务端熔断，单靠客户端参数无法覆盖全部场景
最易被忽略的一点：gRPC 连接性能瓶颈 rarely 出现在 Go 代码层，而是在 TLS 握手、HTTP/2 流控、中间网络设备保活策略上。调优前先抓包看 GOAWAY 帧、TLS Session Reuse 是否生效、SYN 重传是否频繁 —— 别一上来就改 Go 参数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
