gRPC性能优化核心在于连接复用、插件路径配置、并发控制、超时管理、序列化优化及流控设计。必须全局复用grpc.ClientConn，正确安装并配置protoc-gen-go插件，使用grpc.MaxConcurrentStreams和KeepaliveParams限流保活，handler中响应ctx.Done()，避免goroutine泄漏，合理设计proto字段与压缩策略。
grpc.Dial 返回的连接必须复用，否则性能会断崖式下降——这是 Go + gRPC 微服务通信中最容易被忽略、但影响最直接的一点。
protoc 插件安装后找不到 protoc-gen-go 或 protoc-gen-go-grpc
现象是执行 protoc --go_out=. 时提示 “Plugin execution failed: fork/exec … no such file or directory”。这不是 protoc 本身的问题，而是它找不到 Go 插件二进制文件。
- 确认插件已正确安装：
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest和go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest - 检查
$GOPATH/bin是否在系统PATH中（不是GOBIN，也不是$GOROOT/bin）；运行echo $PATH | grep -o "$GOPATH/bin"验证 - macOS 用户若用 Homebrew 安装 protoc，它默认不读取
$GOPATH/bin，需显式指定插件路径：protoc --plugin=protoc-gen-go=$GOPATH/bin/protoc-gen-go ... -
go_package必须与生成目录结构匹配，否则生成的.pb.go文件会 import 错误路径，导致编译失败
服务端并发处理卡在 grpc.NewServer() 默认配置
默认 grpc.NewServer() 不限制并发数，但实际业务中常因 goroutine 泄漏或资源争用导致 CPU 暴涨、连接堆积。这不是代码写错，而是没主动设限。
- 用
grpc.MaxConcurrentStreams(100)控制单个连接最大并发流数，防止单连接耗尽服务端资源 - 搭配
grpc.KeepaliveParams()设置心跳参数，避免空闲连接长期占用：Time: 30 * time.Second, Timeout: 10 * time.Second - 服务端 handler 内部必须用
ctx.Done()做超时或取消响应，否则阻塞 goroutine 不释放 - 不要在 handler 里直接起 goroutine 处理业务逻辑（如
go func() { ... }()），应交由带缓冲的 worker pool 管理
客户端反复调用 grpc.Dial 导致连接爆炸
每次 RPC 都新建 *grpc.ClientConn，会导致大量 TIME_WAIT 连接、TLS 握手开销激增、DNS 频繁解析——实测 QPS 可能从 8000+ 掉到 1200。
立即学习“go语言免费学习笔记（深入）”；
- 全局复用一个
*grpc.ClientConn实例，通常放在包变量或依赖注入容器中 - 务必传入
grpc.WithBlock()（尤其开发期），避免Dial返回未就绪连接；生产环境可改用grpc.WithTransportCredentials+grpc.FailOnNonTempDialError(true) - 连接健康检查不能只靠
conn.GetState()，要配合conn.WaitForStateChange主动监听状态变化 - 如果服务地址动态（如通过 etcd 或 Consul），不要手动拼接 URL，改用
grpc.WithResolvers注册自定义 resolver
proto 字段设计不当引发序列化瓶颈
看似只是加个字段，但 repeated string 或嵌套过深的 message 在高吞吐场景下会让 CPU 花费 40%+ 在 protobuf 编解码上。
- 避免在高频接口中使用
optional（proto3 中默认就是 optional，无需显式声明） -
bytes字段慎用：它不校验内容，但反序列化时仍要拷贝整块内存；大二进制建议走单独文件服务 + URL 引用 - 流式接口（
stream）别滥用：客户端流（client streaming）适合日志聚合，但服务端流（server streaming）若未控制每批消息大小，易触发 TCP 粘包或缓冲区溢出 - 启用压缩仅对 payload > 1KB 的请求有效：
grpc.WithCompressor(gzip.NewCompressor())必须和服务端grpc.RPCCompressor对应，否则静默失效
真正难的不是写出能跑通的 gRPC 代码，而是让连接不泄漏、序列化不拖慢、流控不崩盘——这些细节不在 .proto 里，也不在 protoc 文档里，而在你第一次看到 TIME_WAIT 占满 netstat 输出时的排查记录里。
