gob编码会让RPC响应变慢，因其序列化时携带完整Go类型元信息（如字段名、包路径），导致体积膨胀、依赖反射解析、CPU开销大，实测比protobuf慢2–3倍，且不跨语言、无字段可选和版本演进能力。
为什么gob编码会让RPC响应变慢
gob是net/rpc默认编码器，但它会把Go类型元信息（如字段名、包路径、嵌套结构描述）一并序列化进二进制流，导致体积膨胀、CPU解析开销大。实测相同结构体，gob比protobuf慢2–3倍，尤其在字段多或含map/[]interface{}时更明显。
它也不跨语言，无法与Java/Python服务互通；且不支持字段可选、版本演进能力弱——这些都不是“慢”的全部，但共同构成维护成本高的根源。
如何用protobuf替换net/rpc的gob编码
标准net/rpc不原生支持protobuf，需手动实现rpc.ServerCodec和rpc.ClientCodec接口。关键不是重写整个协议栈，而是包装底层conn，在读写时插入protobuf编解码逻辑：
- 服务端：接收连接后，用
proto.Unmarshal解析请求体，调用方法后用proto.Marshal序列化响应 - 客户端：构造
bytes.Buffer→proto.Marshal→写入conn；读响应后反向解码 - 必须统一
.proto定义，并用protoc-gen-go生成Go代码（推荐v2插件，避免反射开销）
注意：net/rpc本身无服务发现、超时、重试机制，替换编码器后仍需自行补全——这也是多数团队直接迁移到gRPC的原因。
立即学习“go语言免费学习笔记（深入）”；
gRPC中启用protobuf压缩与流控的实际配置
gRPC默认用protobuf+HTTP/2，但压缩和流控需显式开启，否则只是“用了protobuf”，没发挥全部性能：
- 小响应体（grpc.WithInsecure() + 不传
grpc.UseCompressor(gzip.Name)，否则压缩开销反超收益 - 大响应体启用压缩：服务端加
grpc.UnaryInterceptor判断len(respBytes) > 10240再压缩，避免全局开关误伤 - 流控靠
grpc.MaxConcurrentStreams(100)（服务端）和grpc.WithMaxMsgSize(4 * 1024 * 1024)（客户端）配合，防止单连接打满 - 连接保活必须配：
grpc.WithKeepaliveParams(keepalive.ClientParameters{Time: 20*time.Second})，否则NAT网关易断连
漏掉grpc.WithBlock()或context.WithTimeout会导致goroutine泄漏——这是压测时突然OOM的最常见原因。
proto.Unmarshal慢的真正原因和绕过方式
proto.Unmarshal慢，通常不是protobuf本身的问题，而是默认校验太重：
- 默认启用
DiscardUnknown: true，每次都要遍历跳过未知字段，开销显著 - 默认
Merge: false，每次新建对象而非复用，触发GC - 未预分配
[]byte缓冲区，内部多次小内存分配
高频RPC场景应改用：
opts := proto.UnmarshalOptions{
DiscardUnknown: false, // 已知schema一致，可关闭
Merge: true, // 复用目标对象
}
err := opts.Unmarshal(data, msg)再配合sync.Pool缓存*MyRequest指针，msg.Reset()清空后复用——实测GC次数降30%以上。但注意：Reset()不清理未导出字段，若message含自定义缓存逻辑，需额外处理。
