默认 gob 编码在 RPC 中不够快，因其编码体积大、解析慢、不跨语言，高并发或大数据量下 CPU 和带宽消耗高；优化应换用 protobuf+gRPC 或在 net/rpc 上加压缩层。
为什么默认的 gob 编码在 RPC 中不够快
Go 标准库的 net/rpc 默认用 gob 序列化，它虽支持任意 Go 类型，但编码体积大、解析慢，且不跨语言。高并发或大数据量场景下，gob 的 CPU 占用和网络带宽消耗会明显成为瓶颈。尤其当结构体字段多、嵌套深或含大量字符串时，gob 生成的字节流比 JSON 还大，更远不如 Protocol Buffers。
替换序列化：用 protobuf + grpc-go 替代原生 net/rpc
最有效的优化不是“调优 gob”，而是换掉整个协议栈。gRPC 基于 HTTP/2 和 Protocol Buffers，天然支持二进制紧凑编码、流式传输、头部压缩和连接复用。
- 定义接口必须写
.proto文件，用protoc生成 Go 代码（含Unmarshal/Marshal实现） - 服务端用
grpc.NewServer()启动，注册的是实现了xxxServer接口的结构体 - 客户端用
grpc.Dial()连接，调用生成的Client方法，底层自动完成序列化/反序列化 - 避免手动调用
proto.Marshal或proto.Unmarshal—— gRPC 已封装在 call lifecycle 中
service UserService {
rpc GetUser(GetUserRequest) returns (GetUserResponse);
}
message GetUserRequest {
int64 id = 1;
}
message GetUserResponse {
string name = 1;
int32 age = 2;
}
在保留 net/rpc 的前提下启用压缩
如果无法迁移到 gRPC（如需兼容旧客户端），可在 net/rpc 上层加一层压缩。关键点是：压缩必须在编码后、发送前做，解压必须在接收后、解码前做。不能压缩原始 struct，而要压缩 gob 或 json 输出的字节流。
- 推荐用
github.com/klauspost/compress/gzhttp包包装http.ResponseWriter和http.Request，但仅适用于基于 HTTP 的 RPC（如net/rpc/jsonrpc） - 若用 TCP 自定义传输，需自己实现
io.ReadWriteCloser，内部套gzip.NewReader/gzip.NewWriter - 注意：压缩对小消息（1KB 的 payload
- 禁用
gzip的gzip.BestSpeed模式（默认），改用gzip.BestCompression只在服务端出口处设一次，客户端不参与压缩决策
jsonrpc 比 gob 更慢？那为什么还用它
纯性能看，jsonrpc 确实比 gob 慢——JSON 解析开销大、无类型信息、字符串重复多。但它唯一不可替代的价值是**调试友好性与跨语言互通**。生产环境不应直接暴露 jsonrpc 给前端，但可作为内部运维接口（如 Prometheus 指标导出、健康检查端点）。
立即学习“go语言免费学习笔记（深入）”；
- 用
net/rpc/jsonrpc.NewClient连接时，确保服务端启动的是jsonrpc.ServeConn而非gob.ServeConn - 避免在
jsonrpc中传time.Time或map[interface{}]interface{}—— JSON 不支持，会 panic - 若坚持用 JSON，可预编译
encoding/json的Marshaler接口实现，或改用github.com/json-iterator/go加速 2–3 倍
真正容易被忽略的是：序列化优化永远要配合传输层调优。比如 gRPC 的 MaxConcurrentStreams、HTTP/2 的 WriteBufferSize、TCP 的 SO_SNDBUF，这些参数不对齐，再快的序列化也白搭。
