Go的net/rpc默认不支持批量调用，因其基于单请求-单响应模型，无内置请求合并或响应拆包机制；需改用jsonrpc2自定义批量方法或gRPC streaming实现。
为什么 Go 的 net/rpc 默认不支持批量调用
Go 标准库的 net/rpc 是基于单请求-单响应模型设计的，每个 Call 或 Go 调用都对应一次独立的 TCP（或 HTTP）往返。它没有内置的「批量序列化」、「请求合并」或「响应拆包」机制。直接把多个参数塞进一个 struct 传过去，服务端收到的仍是一个请求 —— 这不是批量调用，只是参数聚合。
用 jsonrpc2 + 自定义批量方法实现真批量
最轻量且可控的方式是绕过标准 net/rpc，改用 golang.org/x/net/websocket 或更推荐的 github.com/ethereum/go-ethereum/rpc（即 jsonrpc2 协议栈），自己约定批量格式。核心思路：客户端发一个含多个子请求的数组，服务端统一处理、按序返回结果数组。
- 客户端构造请求体：
[{"jsonrpc":"2.0","id":1,"method":"Arith.Multiply","params":[{"A":2,"B":3}]},{"jsonrpc":"2.0","id":2,"method":"Arith.Divide","params":[{"A":10,"B":2}]}] - 服务端需注册一个新方法（如
Batch.Execute），接收[]json.RawMessage，逐个反序列化、反射调用、捕获 panic、组装响应 - ID 字段必须保留，否则客户端无法匹配响应顺序
- 注意：标准
net/rpc/jsonrpc不解析这种数组，必须自己接管 HTTP handler 或 WebSocket 消息循环
用 gRPC 替代标准 RPC 实现高效批量
如果你能接受引入 gRPC，这是更健壮的选择。gRPC 原生支持 streaming，且可轻松实现批量语义：定义一个 BatchRequest 包含重复字段 repeated Call call = 1;，每个 Call 含 method、args（bytes）、id；服务端用 for range 并行或串行处理。
- 优势：自动压缩、流控、超时传播、TLS 集成、多语言互通
- 注意点：
repeated字段过大时需设max_message_size；并发处理需控制 goroutine 数量，避免context.DeadlineExceeded波及全部子请求 - 不要把所有子请求塞进一个大 context —— 应为每个子请求派生独立
ctx, cancel := context.WithTimeout(parentCtx, subTimeout)
别踩坑：批量 ≠ 并发，也 ≠ 更快
批量调用的价值在于减少网络往返和连接开销，但不等于性能必然提升。实际中容易忽略的关键点：
立即学习“go语言免费学习笔记（深入）”；
- 服务端单次处理 100 个请求，可能因锁竞争或内存分配卡顿，反而比 10 次 10 个请求慢
- 一个子请求 panic 或超时，若没隔离，会导致整批失败（尤其在自定义 JSON 批量里）
- HTTP/1.1 下批量请求仍占满一个 TCP 连接，无法利用多路复用；要真正压榨带宽，得上 HTTP/2 + gRPC
- 日志和 metrics 必须记录每个子请求的耗时与状态，否则排查时你只会看到「Batch.Execute: 2.3s — failed」，却不知道是第 47 个出错了
真正上线前，务必用 pprof 看服务端 CPU 和 GC 分布，再用 go tool trace 确认 goroutine 是否被批量逻辑阻塞。
