Go中RPC并发优化核心是连接复用、批量请求、精细化超时重试及上下文取消，而非盲目增加goroutine；需复用gRPC连接或HTTP Transport，用errgroup限流，并协同服务端流控与压缩。
在 Go 中实现 RPC 并发调用优化，核心不是堆并发数，而是控制好连接复用、请求批处理、超时与重试策略，并合理使用上下文取消机制。盲目增加 goroutine 数量反而容易压垮服务端或耗尽客户端资源。
复用 HTTP/2 或 gRPC 连接
HTTP/1.1 默认每请求建连（除非显式启用 Keep-Alive），而 gRPC 基于 HTTP/2，天然支持多路复用。避免为每次 RPC 新建 client 实例：
- 全局复用一个
*grpc.ClientConn，它本身是线程安全的，可被多个 goroutine 并发调用 - 若用标准 net/rpc + HTTP，确保 Transport 复用：设置
http.DefaultTransport.MaxIdleConns和MaxIdleConnsPerHost（建议 ≥ 100） - 禁用 TLS 会话复用时的证书验证开销（仅测试环境），生产环境务必保留，但可通过
tls.Config.SessionTicketsDisabled = false启用 ticket 复用
批量请求 + 异步等待（Fan-out）
将多个独立 RPC 请求合并为一次批量调用（如自定义 BatchService），或用 goroutine + channel 并行发起、统一收集结果：
- 用
errgroup.Group控制并发上限（如g.SetLimit(16)），避免雪崩 - 每个子请求带上独立 context（带 timeout），防止单个慢请求拖垮整组
- 示例：对 100 个用户 ID 并发查资料，不逐个 go f(id)，而是分 10 组 × 10 并发，每组用 eg.Go 启动
精细化超时与错误分类处理
不同 RPC 调用应有差异化超时策略，且需区分临时性错误（如网络抖动）和永久性错误（如参数校验失败）：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout(ctx, 300*time.Millisecond)替代固定 time.Sleep + select - 对
codes.Unavailable、codes.DeadlineExceeded可有限重试（最多 2 次，指数退避）；对codes.InvalidArgument直接返回 - 记录 slow RPC（如耗时 > 95 分位阈值）并上报 metric，用于后续容量评估
服务端配合：流控与响应压缩
客户端优化效果受限于服务端能力，需协同设计：
- 服务端启用 gRPC 流控（如
grpc.RPCStatsHandler+ 自定义限流中间件） - 对大响应体开启 gzip 压缩：
grpc.WithCompressor(gzip.NewCompressor()) - 避免在服务端做同步 DB 查询后拼装复杂结构体再返回；考虑提前序列化或流式响应（
stream.Send()）
不复杂但容易忽略：压测前先确认 DNS 解析是否缓存、是否启用了 TCP Fast Open、服务端文件描述符限制是否足够。吞吐量瓶颈往往不在代码逻辑，而在系统层配置。
