关键在减少网络传输量和避免阻塞等待：启用gzip压缩大消息体，改用流式传输替代单次响应，结合protobuf序列化与HTTP/2多路复用，可降延迟30%–70%。
提升 Go RPC 响应速度，关键不在重写框架，而在减少网络传输量和避免阻塞等待——压缩和流式传输是两个最直接有效的手段。
启用消息体压缩（如 gzip）
RPC 请求/响应体较大时（比如返回结构体含 JSON 字段、日志列表、批量数据），未压缩的字节流会显著拖慢网络耗时。Go 的 net/rpc 本身不支持压缩，但可通过包装底层连接实现。
- 在客户端 dial 后、服务端 accept 后，用
gzip.NewReader/gzip.NewWriter包裹conn的读写器 - 约定请求头或第一个字节标识是否启用压缩（例如前 4 字节为
0x1f8b表示 gzip 流） - 注意：小消息（2KB 才压缩）
改用流式接口替代单次响应
当业务需要返回大量数据（如导出百万行记录、实时日志推送），传统 RPC “请求-等待-返回完整结果” 模式会造成内存暴涨和长延迟。改用流式可边生成边发送。
- 推荐使用 gRPC（原生支持 streaming），定义
rpc StreamData(Request) returns (stream Response); - 若坚持标准
net/rpc，可手动实现“连接复用 + 分块推送”：服务端持续 write，客户端 goroutine 持续 read + decode - 记得设好
conn.SetWriteDeadline和心跳机制，防止流挂死
配合其他轻量优化
压缩和流式是主力，但需搭配基础调优才能发挥最大效果：
立即学习“go语言免费学习笔记（深入）”；
- 序列化尽量用
protobuf替代JSON（体积小、解析快） - 禁用 HTTP/1.1 的
Keep-Alive复用开销，gRPC 默认走 HTTP/2 多路复用更高效 - 服务端避免在 RPC handler 中做同步 IO 或复杂计算，该异步的异步，该缓存的缓存
基本上就这些。压缩解决“传得多”，流式解决“等得久”，两者结合，多数场景下 RPC 延迟能降 30%–70%。
