grpc.ClientConn 必须全局复用，否则所有调优都白搭；高频调用下吞吐低、延迟毛刺的主因是未复用连接，每次 grpc.Dial 触发完整 TCP+TLS 握手（50–200ms），应初始化单例并注入各服务，仅在服务退出时关闭，多 endpoint 各建一个 conn，配合 Keepalive 防断连，并规避 HTTP/2 退化配置坑。
grpc.ClientConn 必须全局复用，否则所有调优都白搭
高频 gRPC 调用下吞吐上不去、延迟毛刺多，90% 的根因是客户端没复用连接。每次 grpc.Dial 都触发完整 TCP + TLS 握手，耗时动辄 50–200ms，远超业务逻辑本身。复用不是“可选项”，是性能基线。
实操建议：
- 在应用初始化阶段创建单例
*grpc.ClientConn，注入到所有依赖它的 service 或 handler 中 - 显式关闭时机只应在服务退出时（如
defer conn.Close()放在 main 函数末尾），而非每次 RPC 调用后 - 若需多 endpoint（如不同集群地址），每个 endpoint 单独建一个 conn，但不要按请求动态 Dial
- 配合
grpc.WithKeepaliveParams：客户端设Time: 30 * time.Second、Timeout: 10 * time.Second、PermitWithoutStream: true，避免 NAT/代理超时断连
HTTP/2 多路复用失效的三个典型配置坑
即使用了 grpc.Dial，连接也可能退化为“伪 HTTP/2”——多个请求实际走不同 TCP 连接，彻底失去流复用优势。
立即学习“go语言免费学习笔记（深入）”；
常见错误：
-
http.Transport.MaxIdleConnsPerHost设为 0 或过小（如 2），导致连接池无法跨请求复用 - 客户端 TLS 配置里误删
NextProtos，或只保留[]string{"http/1.1"}，强制降级 - 服务端监听用
http.ListenAndServe（HTTP/1.1）而非http.ListenAndServeTLS，根本无法协商 HTTP/2
验证是否真走 HTTP/2：curl -I --http2 https://your-service:8443/health。返回头含 HTTP/2 200 且无重定向才可信。
压缩不是开开关，要按消息大小智能启用
对小消息（
正确做法：
- 服务端注册压缩器：
grpc.RPCCompressor(gzip.Compressor{})和grpc.RPCDecompressor(gzip.Decompressor{}) - 客户端不全局启用，而是在具体调用时按需加选项：
grpc.Invoke(ctx, method, req, resp, conn, grpc.UseCompressor(gzip.Name)) - 更稳妥的方式：封装一个 wrapper 函数，内部判断
proto.Size(req)或响应体预估大小，>1KB 才传grpc.UseCompressor
对象池别只写 sync.Pool，ProtoReflect().Reset() 才是关键
单纯用 sync.Pool 缓存结构体指针，若 Protobuf 消息字段未清空，下次取出时残留旧数据，轻则逻辑错乱，重则 panic。
必须组合使用：
- 从 pool 获取后，立即调用
msg.ProtoReflect().Reset()（gRPC-Go v1.32+ 推荐） - 归还前确保字段已重置，不要依赖 GC 清理或手动置零所有字段（易漏）
- Pool 的 New 函数应返回已调用
Reset()的干净实例，例如：&pb.EchoRequest{}; msg.ProtoReflect().Reset()
真正影响性能的从来不是某一行代码，而是连接生命周期管理、HTTP/2 底层帧调度、Protobuf 内存布局这些看不见的链路。调参容易，但搞错一层依赖关系，整套优化就卡在瓶颈之外。
