Go RPC性能优化核心是减少序列化开销、降低网络往返、避免阻塞I/O及合理并发控制；推荐gRPC+Protobuf或MsgPack替代Gob，复用连接，批量合并请求，异步调用，并精简服务端逻辑。

Go 的 RPC 性能优化核心在于减少序列化开销、降低网络往返、避免阻塞式 I/O，并合理控制并发与资源复用。默认的 net/rpc（基于 Gob）在高并发低延迟场景下容易成为瓶颈，需针对性调整。

使用更高效的序列化协议

Gob 编码体积大、解析慢，且不支持跨语言。生产环境推荐切换为 Protocol Buffers（gRPC）或 MsgPack：

• gRPC + Protobuf：二进制紧凑、多语言支持、内置流控与连接复用，延迟通常比 Gob 低 30%~50%
• MsgPack：轻量级二进制格式，兼容 JSON 接口习惯，go-codec/msgpack 库可直接替换 Gob 编解码器，无需改业务逻辑
• 避免在 RPC 参数中传递大结构体或原始字节切片；优先传 ID 或摘要，由服务端按需加载

复用连接与客户端实例

每次调用新建 TCP 连接会引入三次握手和 TLS 握手（如启用 HTTPS），显著增加延迟。应全局复用连接：

• gRPC 客户端是线程安全的，创建一次即可长期复用；设置 WithTransportCredentials 或 WithInsecure 后，内部自动维护连接池
• 若用自定义 HTTP/JSON-RPC，用 http.Client 并配置 Transport.MaxIdleConns 和 MaxIdleConnsPerHost（建议 ≥200）
• 避免在 handler 内 new client；将 client 作为依赖注入或全局变量初始化

异步调用与批量合并

对非强实时依赖的请求，可聚合多个小请求为单次批量调用，减少网络往返次数：

• 设计 BatchGet([]string keys) ([]*Item, error) 类接口，服务端并行查 DB/Cache，再统一返回
• 使用 context.WithTimeout 控制整体超时，而非每个子请求单独设超时
• 对非关键路径，考虑用 channel + goroutine 异步触发 RPC，主流程不等待结果（注意错误处理和重试策略）

精简服务端处理逻辑

RPC 延迟不仅来自网络，也来自服务端 CPU 占用过高导致排队：

• 禁用反射式参数解包（如 net/rpc 默认行为）；改用 codegen 方式（如 gRPC 的 protoc-gen-go）提前生成编解码函数
• 服务端 handler 中避免同步写日志、调用未缓存的外部 API、或执行长循环；耗时操作放入 worker pool（如 ants 或自建 goroutine 池）
• 开启 pprof，在压测时采集 /debug/pprof/profile?seconds=30，定位 CPU 热点（常见于 JSON 解析、Gob decode、锁竞争）