gRPC性能优化需从连接复用、超时控制、序列化精简、服务端资源隔离四层面入手：全局复用ClientConn、显式设Context超时、避免大结构体传输、阻塞操作须响应ctx.Done()。
复用连接，避免频繁建连开销
HTTP/2 或 gRPC 默认支持长连接复用，但若每次调用都新建 client（比如在 handler 内 new grpc.Dial），会反复经历 DNS 解析、TCP 握手、TLS 协商，延迟飙升。正确做法是全局复用一个 *grpc.ClientConn，启动时建立，整个服务生命周期内共享。
示例：
- 在 main 初始化时 dial 并保存到全局变量或依赖容器中
- 确保调用方不调用 conn.Close()，除非服务退出
- 配合 WithBlock() 和 WithTimeout() 控制建连等待，避免阻塞启动
启用流控与合理设置超时
默认 gRPC 客户端无超时，可能因后端卡顿导致调用堆积、goroutine 泄漏。每个 RPC 调用必须显式设 Context.WithTimeout，且服务端也应尊重该 deadline 做快速失败。
建议值参考：
立即学习“go语言免费学习笔记（深入）”；
- 内部强依赖服务：300–500ms
- 弱依赖或降级场景：100ms 内，超时直接返回默认值
- 避免所有接口统一用 5s —— 掩盖真实瓶颈，拖慢整体 P99
减少序列化/反序列化负担
Protobuf 本身高效，但字段设计不当仍会拖慢。避免在高频 RPC 中传递大结构体（如含 []byte、嵌套深的 map、未压缩的 base64 图片）。
- 用 optional 和 oneof 减少冗余字段传输
- 对体积敏感字段（如日志上下文、调试信息）单独走 header 或 metadata，不进 message body
- 必要时启用 gRPC 的 compressor（如 gzip），但需权衡 CPU 与带宽
服务端并发与资源隔离
gRPC Server 默认使用 Go 默认调度器，若单个 handler 耗 CPU 或阻塞 IO（如同步 DB 查询、未加 context 的 http.Get），会拖慢其他请求。应做到：
- 所有阻塞操作必须传入 ctx，并在 ctx.Done() 时及时退出
- 对慢依赖（如外部 HTTP、Redis）做熔断或异步 fallback，不串行等待
- 用 runtime.GOMAXPROCS 和 server options（如 MaxConcurrentStreams）防止单实例过载
