用 gob 替换默认 JSON 编码器可提升吞吐量 2–4 倍，需服务端显式注册并使用 ServeCodec，客户端配 gob 编解码器，结构体须导出且定义一致；RPC 方法中禁用阻塞操作，须用 context 控制超时；连接应复用而非频繁 Dial；长期演进推荐迁移到 gRPC。
用 gob 替换默认 JSON 编码器能显著提升吞吐量
Go 的 net/rpc 默认使用 jsonrpc，但 json 序列化/反序列化开销大、不支持私有字段、无类型信息，对高频 RPC 场景是明显瓶颈。改用 Go 原生的 gob 编码器后，实测 QPS 可提升 2–4 倍（取决于 payload 大小和结构嵌套深度）。
关键点：
- 服务端注册时需显式调用
rpc.RegisterName并搭配rpc.NewServer()+server.RegisterName，再用http.Serve或listener.Accept手动处理连接 - 客户端必须用
rpc.DialHTTP或rpc.Dial并传入自定义ClientCodec，例如gob.NewDecoder/gob.NewEncoder包装的连接 -
gob要求结构体字段首字母大写（导出），且服务端与客户端 struct 定义必须完全一致（包括字段顺序、tag、嵌套层级），否则解码失败静默丢包
func main() {
server := rpc.NewServer()
server.RegisterName("Arith", new(Arith))
listener, _ := net.Listen("tcp", ":1234")
for {
conn, _ := listener.Accept()
// 使用 gob 编解码
go server.ServeCodec(gob.NewGobServerCodec(conn))
}
}
避免在 RPC 方法中做阻塞 I/O 或长耗时计算
RPC 方法体本质运行在服务端 goroutine 中，若内部调用 time.Sleep、同步数据库查询、未加 context 控制的 HTTP 调用等，会直接卡住该连接对应的 handler goroutine，导致并发能力断崖下降。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 所有外部依赖调用必须带
context.Context，并设超时（如ctx, cancel := context.WithTimeout(r.Context(), 500*time.Millisecond)） - 数据库操作优先走连接池（如
sql.DB），禁用database/sql的单连接模式 - 禁止在方法内启动无管控的 goroutine（如
go heavyWork()），除非明确 spawn 后立即返回且结果通过回调或 channel 异步通知 - 若确实需要异步响应，应改用消息队列或流式 RPC（gRPC Streaming），而非在传统
net/rpc上硬扛
net/rpc 连接复用比频繁 Dial 更关键
每次 rpc.Dial 都新建 TCP 连接，三次握手 + TLS 握手（如果启用）+ 连接池初始化，延迟高且资源浪费。实测连续 100 次 Dial 耗时可能超过一次复用连接下 100 次调用总和。
建议方式：
- 客户端全局复用一个
*rpc.Client实例（它本身是线程安全的） - 避免在请求函数内
defer client.Close()—— 这会导致连接被立即关掉 - 如需控制生命周期，用
sync.Pool管理*rpc.Client，但注意 Pool 中对象不可保证存活，仍需检查client == nil || client.Closed() - 连接空闲超时由服务端
http.Server.ReadTimeout或底层net.Conn.SetReadDeadline控制，客户端无需主动探测
用 gRPC 替代 net/rpc 是更彻底的优化路径
原生 net/rpc 缺少拦截器、负载均衡、健康检查、流控、指标暴露等现代 RPC 必备能力，且协议扩展性差。当业务规模增长、需跨语言互通或接入服务网格时，net/rpc 会迅速成为技术债中心。
迁移要点：
- IDL 用
.proto定义 service 和 message，生成 Go 代码后，server 实现xxxServer接口，client 用xxxClient - 默认使用
Protocol Buffer编码，体积比 JSON 小 3–5 倍，解析快 2–6 倍；启用gzip压缩可进一步降低带宽占用 - 务必配置
WithBlock()+WithTimeout()控制连接建立阶段，否则grpc.Dial可能无限等待 DNS 解析或后端就绪 - 不要忽略
grpc.StatsHandler和otelgrpc，可观测性缺失会让性能问题排查变成盲人摸象
真正卡点往往不在编码格式或连接复用，而在于调用链路中某一级没设超时、某次反序列化 panic 后没 recover 导致 goroutine 泄漏、或者 protobuf message 字段类型误用（如用 int32 传时间戳导致溢出）。这些细节比选型更决定最终稳定性。
