gob在rpc中cpu占用高是因为其设计未适配rpc场景，需全量反射、序列化完整类型路径且无法跳过header解析，导致encodevalue和fieldbyindex等操作开销巨大。
Go net/rpc 默认用 gob 编码，CPU 损耗高不是因为“写得烂”，而是它根本没为 RPC 场景设计——每次调用都在做全量反射、塞入完整类型路径、无法跳过 header 解析。不换协议，光调参数基本无效。
为什么 gob 在 RPC 中 CPU 占用高得离谱
gob 的编码逻辑和 RPC 帧结构强耦合：method name、seq、error 和 body 全塞进同一个流，反序列化时必须从头读完才能知道调的是哪个方法；字段越多、嵌套越深，reflect.ValueOf 遍历开销线性增长；更麻烦的是，它把 "main.User" 这种包路径也序列化进去，导致解码时要反复做字符串比对和类型重建。
常见现象包括：
- pprof 显示
encoding/gob.(*Encoder).encodeValue或reflect.Value.FieldByIndex占 CPU 30%+； - 相同 payload 下，
gob反序列化耗时是protobuf的 4–6 倍； - 并发稍高（>200 QPS），GC pause 明显拉长，
runtime.mallocgc上升。
替换 gob 时必须绕开 net/rpc 的坑
直接把 jsonrpc 当成“换序列化格式”方案是错的：encoding/json 同样重度依赖 reflect，且用字符串 key 查找字段（比如 "user_id"）比 gob 的整型索引慢得多；更关键的是，jsonrpc 包靠读取 \n 分隔的 JSON 对象模拟分帧，TCP 粘包后会直接卡死或 panic。
可行路径只有两条：
- 彻底迁移到
grpc-go+protobuf：编译期生成代码，零反射，字段访问走偏移直取； - 若必须保留
net/rpc接口兼容性，改用github.com/vmihailenco/msgpack/v5并预注册类型，禁用反射（加msgpack:"struct"标签 +msgpack.Register）；
别碰 encoding/xml 或手写 ServerCodec——前者体积更大，后者要自己处理 header/body 分界、错误传播、连接生命周期，出错概率远高于收益。
sync.Pool 复用缓冲区只在特定位置有效
在 net/rpc 场景下，sync.Pool 不是用来缓存 gob.Encoder 实例的（它内部持有一个 *bytes.Buffer，但每次 encode 都会重置，复用意义不大），真正该池化的对象是：
- 预分配的
[]byte切片（比如固定 4KB），用于接收 TCP 数据后先 copy 进来，再喂给解码器； - RPC 请求/响应结构体指针（前提是生命周期可控，比如短连接、有界 goroutine）；
- 如果用了
msgpack，可池化msgpack.Decoder，但它必须绑定到一个io.Reader，所以得配合bytes.NewReader使用，不能直接池化底层 reader。
错误做法：把 gob.NewDecoder(conn) 放进 pool——conn 是网络连接，不可复用；把未清空字段的 struct 指针放 pool——下次 decode 会残留旧值，引发数据污染。
压缩不是万能解药，反而可能加重 CPU 压力
在 net/rpc 上加 gzip，必须在 gob.Encode 完成后、Write 到 conn 前做；解压则要在 Read 完字节流后、gob.Decode 前做。但要注意：
- 小消息（
）压缩后体积变化微乎其微，却多一次 CPU 计算，P99 延迟反而上升； -
gob输出本身已含冗余类型信息，gzip 对它的压缩率通常只有 15–25%，远低于对纯文本或 protobuf 的 60%+； - 若服务端 CPU 已接近饱和，启用压缩等于雪上加霜，监控
go:cpu:profile会看到compress/gzip.(*Writer).Write突然冲高。
真正值得压的，是迁移到 protobuf 后的大 payload（如二进制 blob 字段），此时再配 grpc.WithCompressor(gzip.NewCompressor())，才有明确收益。
最常被忽略的一点：gob 的性能问题无法通过调优修复，只能替换。任何试图在 net/rpc 框架内“优化 gob”的尝试，最终都会撞上反射和帧协议耦合这两堵墙。
