Go net/rpc默认gob编码因保存完整类型信息、依赖反射、不支持零拷贝和跨语言，导致体积大、性能低；推荐升级为protobuf+gRPC栈，或保留net/rpc时改用Msgpack并注意兼容性与连接复用。
Go 底层 net/rpc 的序列化与反序列化损耗主要来自三处：反射开销、类型元信息冗余、以及编解码器与 RPC 帧协议耦合过紧。默认的 gob 不是“慢”，而是为 Go 内部调试场景设计的——它把包路径、字段名、接口实现类型全塞进字节流，导致体积大、解析慢、无法跨语言，且无法规避运行时反射。
为什么 gob 在 RPC 场景下损耗高
gob 的设计目标是“Go 到 Go 的安全保真传输”，不是“高性能网络通信”。它在 RPC 中暴露的问题很具体：
- 每次编码都触发完整反射遍历结构体，字段越多、嵌套越深，CPU 时间线性增长；
- 序列化结果包含完整类型描述（如
"main.User"、"github.com/x/y.Z"），相同数据比protobuf大 40%–60%； - 不支持零拷贝或预分配缓冲区，
gob.Encoder内部频繁 newbytes.Buffer，加剧 GC 压力； - RPC 帧头（method name、seq、error）和 body 共享同一
gob流，无法单独压缩 body 或跳过 header 解析。
net/rpc/jsonrpc 的反射与分帧陷阱
用 jsonrpc 替换 gob 并不能解决问题，反而引入新瓶颈：
-
encoding/json同样重度依赖reflect，且字符串 key 查找比gob的整型字段索引更慢； - JSON 没有原生分帧机制，
jsonrpc包靠读取\n分隔的 JSON 对象模拟帧，但实际网络中 TCP 是字节流，容易粘包/拆包，需额外状态管理； - RPC header（方法名、序列号）被硬编码进 JSON 字段（如
{"method":"Arith.Add","params":[...],...}），导致每次调用都要解析整个 JSON 对象，无法短路判断 method 是否合法； - 空接口（
interface{}）字段反序列化必然失败，报错json: cannot unmarshal object into Go value of type main.Foo—— 因为 JSON 不携带类型信息，而net/rpc又没提供类型注册钩子。
替换 codec 时最常踩的兼容性坑
想用 msgpack 或自定义 ServerCodec 替换默认编码器，必须手动处理 RPC 协议语义，否则服务端收不到请求或客户端解不出响应：
-
ReadRequestHeader必须能从原始字节中无歧义提取 method name 和 seq；msgpack本身无 header 概念，需约定前 N 字节为 header 长度+内容，或用 length-prefixed framing； -
ReadRequestBody不能直接msgpack.Unmarshal(buf, &v)，因为v是空接口，需提前知道其具体类型并传入指针； - 客户端调用
rpc.Dial后，必须显式client.RegisterCodec(..., "msgpack")，且服务端server.ServeCodec用的 codec 实例必须与之匹配，否则静默失败； - 字段 tag 必须统一（如
msgpack:"id"），json:"id"或gob:"id"会被忽略，且大小写敏感——ID字段若 tag 写成msgpack:"id"，解码后就是零值。
真正降损的关键不在“换格式”，而在“绕开 net/rpc”
所有在 net/rpc 框架内折腾 codec 的优化，收益都有限。根本原因是它的抽象层级太低：它把“网络连接管理”“帧解析”“编解码”“错误传播”全耦合在一个接口里，没法单独替换某一块。生产环境真正有效的降损路径只有一条：
- 用
gRPC替代net/rpc：底层基于 HTTP/2 多路复用，header/body 天然分离，protobuf编译期生成代码，零反射、字段偏移直取； - 禁用运行时反射：不要在 handler 里用
json.Marshal(interface{})或map[string]interface{}，所有 RPC 参数/返回值必须是生成的 struct 指针； - 压缩只作用于 body：gRPC 的
WithCompressor(gzip.NewGZIPCompressor())不压缩 header，且可按 payload size 动态开关（比如 >1KB 才压）； - 连接池必须由客户端控制：
grpc.Dial创建的 conn 是长连接池，复用率接近 100%，而net/rpc的Dial默认每次新建 TCP 连接。
最后提醒一点：很多团队卡在“迁移成本高”上，但真实瓶颈往往不是改 proto 文件，而是业务代码里大量 interface{} 和 map[string]interface{} 的泛化用法——这些才是反序列化时无法绕过的反射源头。
