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，如何最小改动提效
不重写业务逻辑的前提下，只替换编码器是可行的，但需注意兼容性断层：
立即学习“go语言免费学习笔记（深入）”；
- 不能直接用
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/rpchandler 里做 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 生态，才能释放全部收益。
