Go RPC高并发优化核心是稳连接、控并发、减开销、松服务端：复用长连接池、限制goroutine并发数、选用Protobuf等高效序列化协议、服务端避免阻塞并合理注册方法。
Go 的 RPC（尤其是 net/rpc 和基于 HTTP 的 jsonrpc）默认是同步阻塞的，高并发下容易成为瓶颈。优化核心在于：减少单次请求延迟、提升连接复用率、控制并发资源、避免序列化/反序列化开销。以下几点是实战中见效快、易落地的关键技巧。
复用连接 + 使用长连接池
每次 RPC 调用新建 TCP 连接（尤其短连接）开销大，且受系统文件描述符限制。应主动复用连接：
- 客户端使用
http.Transport配置连接池（适用于基于 HTTP 的 RPC，如 JSON-RPC over HTTP）：MaxIdleConns、MaxIdleConnsPerHost设为合理值（如 100），IdleConnTimeout建议 30s； - 自定义
rpc.Client时，传入已建立的*http.Client或复用net.Conn（如用rpc.NewClientWithCodec+ 自定义ClientCodec）； - 避免在高并发循环中反复调用
rpc.Dial或rpc.DialHTTP，改为初始化一次连接池或共享 client 实例。
控制并发数 + 避免 Goroutine 泛滥
无节制启 Goroutine 发起 RPC 请求，会快速耗尽内存和调度器压力，反而降低吞吐。需主动限流：
- 用
semaphore（如golang.org/x/sync/semaphore）或带缓冲 channel 控制最大并发请求数（例如 50～200，视服务端承载能力而定）； - 配合
context.WithTimeout或context.WithDeadline设置单次 RPC 超时（建议 ≤ 1s），防止慢请求拖垮整体； - 慎用
go rpcClient.Call(...)直接发请求，优先走统一调度层（如 worker pool）做排队与熔断。
减少编解码开销 + 选对序列化协议
默认 gob 效率尚可但不跨语言；JSON 易读但解析慢、内存占用高。高并发场景应优化：
立即学习“go语言免费学习笔记（深入）”；
- 服务端与客户端协议一致前提下，优先选用 Protocol Buffers（gRPC） 或 FlatBuffers，序列化/反序列化性能比 JSON 高 3–10 倍；
- 若必须用标准
net/rpc，可实现自定义ServerCodec/ClientCodec替换默认gob，接入更轻量编码器（如msgpack）； - 避免在参数中传递大结构体或原始字节切片，考虑分页、字段裁剪或 ID 引用代替嵌套数据。
服务端优化：避免阻塞 + 合理注册方法
服务端性能常被忽略，但它是并发瓶颈的终点：
- RPC 方法内禁止阻塞操作（如同步 DB 查询、未设超时的 HTTP 调用），应转为异步或使用带上下文的非阻塞客户端；
- 注册方法时避免全局锁竞争，不用
rpc.Register动态注册热更新，推荐启动时一次性注册； - 对高频低耗方法（如健康检查、计数器），考虑绕过 RPC 框架，直接暴露 HTTP handler 提升效率。
基本上就这些。Golang RPC 高并发不是靠堆 Goroutine，而是靠稳连接、控并发、减开销、松服务端。用好 context、连接池、限流器和高效 codec，QPS 提升 2–5 倍很常见。
