Go语言RPC性能优化需多层协同：首选Protocol Buffers等高效序列化协议，精简数据结构，启用gRPC压缩，复用连接并支持批量调用，且必须基于真实数据压测验证效果。
Go 语言的 RPC 默认使用 gob 编码，虽然简单易用，但体积大、解析慢、跨语言支持差，不适合高并发或微服务场景。要提升传输效率，关键不是“换一个序列化库”就完事，而是结合协议选型、数据结构设计、编码压缩和连接复用等多层优化。
选择更高效的序列化协议
gob 的二进制格式未压缩、无 schema、反射开销大。生产中推荐：
-
Protocol Buffers（protobuf）：强 schema、紧凑二进制、多语言支持好；配合
google.golang.org/protobuf和grpc-go使用，是 gRPC 的默认底层； - FlatBuffers：零拷贝解析，适合延迟敏感场景（如游戏、实时通信），但 Go 生态工具链稍弱；
- Cap’n Proto：类似 FlatBuffers，性能优异，但社区维护活跃度不如 protobuf；
- 若必须兼容原生
net/rpc，可用json-iterator/go替代标准encoding/json，性能提升 2–5 倍，且无需改接口定义。
精简传输数据结构
序列化耗时与字段数量、嵌套深度、字符串长度强相关。避免“传整个 struct”：
- 定义专用的
RPCRequest/RPCResponse类型，只包含必要字段； - 用
int32替代int（明确宽度，避免平台差异）； - 字符串尽量短，敏感字段（如 token、content）考虑哈希后传输 ID；
- 避免在 RPC 参数中传递函数、channel、interface{} 等无法序列化的类型；
- 对 slice/map 做预判空值处理，空集合不序列化（protobuf 中设
optional或用oneof控制）。
启用压缩与二进制流优化
网络 I/O 往往是瓶颈，压缩能显著减少带宽占用（尤其文本类 payload）：
- gRPC 支持内置压缩（
gzip、zlib），客户端和服务端需同时开启：grpc.WithCompressor(gzip.NewGZIPCompressor())； - 自建 net/rpc + 自定义 codec 时，可在
ClientCodec/ServerCodec层包装zlib.Reader/zlib.Writer； - 注意权衡：小消息（2KB 再启用；
- 避免在 TLS 层已启用 HTTP/2 流压缩的前提下重复压缩。
复用连接与批量调用
每次 RPC 建连（TCP + TLS）耗时远高于序
列化本身。优化方向：
- gRPC 默认复用 HTTP/2 连接，确保客户端使用单个
grpc.ClientConn实例，不要每次 New； - 对高频低负载请求（如心跳、状态查询），改用长连接 + 自定义帧协议（如 length-prefixed + protobuf），绕过 RPC 框架开销；
- 支持批量（batch）接口：将多个逻辑请求合并为一个 RPC 调用（例如
GetUsers([]int64{1,2,3})），降低往返次数（RTT）； - 设置合理的超时与重试策略，避免因单次失败触发重建连接。
不复杂但容易忽略：序列化优化效果高度依赖实际 payload 特征。上线前务必用真实数据做 benchmark，对比 gob/protobuf/json-iter/gzip 组合的吞吐、延迟、内存占用——有时最简单的 json + gzip 就比 protobuf 更快，因为省去了编解码器初始化和 proto runtime 开销。
