Go net/rpc 默认gob编码因保存完整类型信息、依赖反射、不支持零拷贝和跨语言，导致体积大、性能低；推荐升级为protobuf+gRPC栈，或保留net/rpc时改用Msgpack并注意兼容性与连接复用。

Go 的 net/rpc 默认使用 gob 编码，它安全、支持反射，但序列化体积大、性能一般，尤其在高并发或跨语言场景下容易成为瓶颈。想提升 RPC 数据编码效率，核心不是“换不换”，而是“换什么、怎么换、换完要注意什么”。

为什么默认 gob 编码慢且占带宽

gob 是 Go 专用二进制格式，会完整保存类型元信息（如结构体字段名、包路径），导致：

• 相同数据比 JSON 小，但比 Protobuf / FlatBuffers 大 30%–60%
• 编码/解码依赖运行时反射，无法内联，CPU 开销高
• 不支持零拷贝、无 schema 预编译，每次调用都要解析类型结构
• 跨语言调用完全不可行

用 protobuf + grpc-go 替代标准 net/rpc

这是目前最主流、实测收益最高的方案。不是简单“换序列化器”，而是升级整个 RPC 栈：

• 定义 .proto 文件后，protoc 生成强类型 Go 代码，编解码全程无反射
• grpc-go 底层复用 HTTP/2 连接池和流控，吞吐量比 net/rpc 高 3–5 倍
• 所有字段默认可选、支持 packed 编码，对 repeated int32/bool 等类型压缩效果显著
• 务必开启 WithCompressor(gzip.NewGZIPCompressor())（服务端/客户端都要配）应对文本类 payload

service UserService {
  rpc GetUser(UserRequest) returns (UserResponse);
}
message UserRequest {
  int64 id = 1;
}
message UserResponse {
  string name = 1;
  int32 age = 2 [(gogoproto.casttype) = "int32"];
}

如果必须保留 net/rpc，如何最小改动提效

不重写业务逻辑的前提下，只替换编码器是可行的，但需注意兼容性断层：

• 不能直接用 json.RawMessage 或 []byte 当参数——net/rpc 要求参数/返回值是导出结构体
• 推荐用 github.com/ugorji/go/codec 的 MsgpackHandle：比 gob 快 2x，体积小 40%，且仍纯 Go 实现
• 注册前必须显式设置：rpc.RegisterCodec(codec.MsgpackSpecRpc)，否则服务端收不到请求
• 客户端 Dial 后要调用 client.RegisterCodec(codec.MsgpackSpecRpc, "msgpack") 并指定 codec 名
• MsgPack 不校验字段名，结构体字段 tag 必须统一为 codec:"field_name"，否则解码为空

避免踩坑：压缩、连接复用与错误传播

编码优化只是链路一环，忽略以下三点，性能提升会打折扣：

• HTTP/2（gRPC）或自定义 TCP 连接池必须复用，rpc.DialHTTP 每次新建连接会吃掉 50ms+ RTT
• 不要在 net/rpc handler 里做 gzip 压缩——它发生在应用层之下，应由传输层（如 nginx）或 gRPC 的 compressor 统一处理
• gRPC 的 Status 错误码会被序列化进 trailer，而 net/rpc 只能靠返回 error 字符串，跨语言时建议统一用 google.rpc.Status 嵌入 response body
• Protobuf 的 oneof 和 map 在 Go 中生成的是指针字段，空值不会被编码，但反序列化后 nil map 会导致 panic，务必初始化

真正卡住 RPC 性能的，往往不是序列化本身，而是没意识到编码器和传输层、连接模型、错误语义是耦合在一起的。改 gob 为 protobuf 时，连带把超时控制、重试策略、metric 上报也一并迁移到 gRPC 生态，才能释放全部收益。