关键在于协同启用gRPC原生流式传输与压缩机制：服务端配置RPCCompressor/Decompressor，客户端显式UseCompressor；用stream替代Unary减少往返；精简Protobuf结构降低编解码开销；全局复用ClientConn实现连接池管理。
提升 Go 语言中 gRPC 调用性能，关键不在“换框架”，而在于合理利用 gRPC 原生支持的流式传输和压缩机制——它们能显著减少往返次数、降低网络开销、缓解序列化瓶颈。
启用消息压缩，减小传输体积
gRPC 默认不开启压缩，但对文本类 payload（如 JSON 结构的 Protobuf 消息）效果明显。服务端和客户端需协同配置，仅单侧开启无效。
- 服务端在 ServerOption 中启用 gzip 压缩：grpc.KeepaliveParams(keepalive.ServerParameters{MaxConnectionAge: 30 * time.Minute}) 不是压缩，真正要用的是 grpc.RPCCompressor(gzip.Compressor{}) 和 grpc.RPCDecompressor(gzip.Decompressor{})
- 客户端调用时显式声明压缩方式：grpc.UseCompressor(gzip.Name)，否则即使服务端支持，客户端仍发未压缩数据
- 注意：小消息（2KB 的响应统一启用，并通过 grpc.WithDefaultCallOptions(grpc.UseCompressor(gzip.Name)) 全局设置
用流式 RPC 替代多次一问一答
传统 Unary RPC 每次调用都有固定延迟（TCP 握手、TLS 协商、HTTP/2 帧开销），高频小请求极易成为瓶颈。流式传输复用连接，批量处理，延迟可降 50%+。
- 定义 streaming 方法：在 .proto 中使用 stream 关键字，例如 rpc StreamLogs(LogRequest) returns (stream LogResponse);
- 服务端用 stream.Send() 连续推送，避免阻塞；客户端用 stream.Recv() 循环读取，配合 context 控制超时与取消
- 适合场景：实时日志推送、传感器数据上报、分页结果流式返回（替代 offset/limit）、大文件分块上传——但注意流长期空闲可能被中间代理断连，需配 keepalive
精简 Protobuf 结构，降低编解码开销
压缩和流式解决的是“传得多”和“传得频”的问题，而结构臃肿会拖慢序列化本身——尤其在高 QPS 下，CPU 可能比网络先打满。
立即学习“go语言免费学习笔记（深入）”；
- 避免嵌套过深或冗余字段，用 optional 显式标记可选字段（Protocol Buffers v3.12+ 支持），减少默认值填充开销
- 字符串字段慎用 bytes 类型模拟二进制，Protobuf 对 bytes 的 base64 编码/解码成本高于原生 binary
- 数值优先用 sint32/sint64（zigzag 编码），比 int32/int64 在负数场景更省空间；枚举值从 0 开始编号，利于编码压缩
连接复用与连接池管理
gRPC 默认复用底层 HTTP/2 连接，但若客户端频繁创建新 conn（比如每个请求 new grpc.Dial），会抵消所有优化效果。
- 全局复用一个 *grpc.ClientConn 实例，它线程安全，可并发用于多个 RPC 调用
- 设置合理的连接参数：grpc.WithBlock() 避免 Dial 异步返回未就绪 conn；grpc.WithTimeout(5 * time.Second) 防止 DNS 卡死；grpc.WithKeepaliveParams() 维持长连接活性
- 服务端可通过 grpc.KeepaliveEnforcementPolicy() 拒绝低质量心跳，避免被恶意客户端拖垮
基本上就这些。压缩、流式、结构精简、连接复用——四者不是互斥选项，而是层层递进的协同策略。不复杂但容易忽略。
