gob编码让RPC响应变慢是因为它写入大量类型元信息，导致序列化体积大、CPU消耗高，尤其在字段多或嵌套深时更明显，实测比JSON慢30–50%，比Protobuf慢2–3倍。
为什么 gob 编码会让 RPC 响应变慢
gob 是 Go 标准库 net/rpc 的默认编码器，但它不是为高性能网络传输设计的。它会写入大量类型元信息，序列化后体积大、CPU 消耗高，尤其在结构体字段多或嵌套深时更明显。实测中，相同数据用 gob 比 json 多 30–50% 序列化时间，比 protobuf 高出 2–3 倍。
- 避免在高吞吐场景下直接使用
rpc.Register+ 默认gob编码 - 若必须用标准
net/rpc，可替换为jsonrpc（需手动包装json.ServerCodec） - 更推荐迁移到
gRPC或自定义二进制协议，用protocol buffers定义服务和消息
如何用 gRPC 替代原生 net/rpc 并启用流控
gRPC 不仅自带高效 protobuf 编码，还支持连接复用、头部压缩、deadline 控制和内置流控机制。关键不是“换框架”，而是把 net/rpc 中隐式依赖的长连接、重试、超时等逻辑显式收归到 gRPC 的 ClientConn 和 CallOption 中管理。
- 服务端启动时设置
KeepaliveParams，例如ServerParameters{MaxConnectionAge: 30 * time.Minute} - 客户端调用必须传
context.WithTimeout，否则一次卡死会拖垮整个连接池 - 禁用默认的
gzip压缩（小包反而增开销），大响应体再按需启用：grpc.UseCompressor(gzip.Name)
conn, _ := grpc.Dial("localhost:8080",
grpc.WithTransportCredentials(insecure.NewCredentials()),
grpc.WithKeepaliveParams(keepalive.ClientParameters{
Time: 10 * time.Second,
Timeout: 3 * time.Second,
PermitWithoutStream: true,
}),
)
net/rpc 连接池没做对，吞吐量就上不去
标准 net/rpc 自身不提供连接池，rpc.Dial 每次新建 TCP 连接，而 rpc.Client 实例也不是线程安全的。常见错误是全局复用一个 *rpc.Client，或每次请求都 Dial + Close —— 前者导致并发阻塞，后者触发频繁三次握手与 TIME_WAIT。
- 每个 goroutine 不要共享
*rpc.Client；改用sync.Pool管理已建立的 client 实例 - 连接复用前提：服务端必须启用
http.Serve或rpc.ServeConn复用底层 conn，而非每请求启新 goroutine - 客户端侧可封装带健康检查的简易池，例如用
net.Conn检查Write是否返回io.EOF再决定是否回收
响应体过大时，proto.Marshal 成为性能瓶颈
即使用了 protobuf，如果响应结构体包含未清理的空切片、冗余字段或嵌套过深的 map，proto.Marshal 仍可能占用 10ms+ CPU 时间。这不是 GC 问题，而是序列化路径上反复反射判断字段有效性所致。
立即学习“go语言免费学习笔记（深入）”；
- 生成 proto 代码时加
--go_opt=paths=source_relative，避免 import 路径引发的 init 开销 - 响应 struct 在 encode 前主动调用
proto.CompactTextString验证字段合法性，提前暴露 nil 指针或非法 enum - 对高频接口，用
unsafe.Slice+ 手写二进制打包替代proto.Marshal（仅限字段稳定、无嵌套、无 optional 的场景）
真正卡住吞吐的，往往不是网络延迟，而是单次响应里那几毫秒的序列化抖动 —— 它让并发请求排队等待，放大了整体 P99 延迟。
