net/rpc 默认不支持重试因其同步阻塞模型直接透传底层连接错误，无错误分类、上下文控制或重试策略；需手动封装基于 context.WithTimeout 的循环重试逻辑，仅对临时性网络错误重试。
为什么默认的 net/rpc 不支持重试
Go 标准库的 net/rpc 是同步阻塞模型，Client.Call 或 Client.Go 发起请求后，底层直接调用 conn.Write 和 conn.Read，一旦网络出错（比如 connection refused、i/o timeout）或服务端 panic 导致连接中断，错误会立即返回，没有任何重试逻辑。它不区分临时性错误和永久性错误，也不提供上下文控制或重试策略接口。
用 context.WithTimeout + 手动循环实现可控重试
最轻量、最可控的方式是封装一层带重试的调用函数，用 context 控制单次请求超时，并在外层循环处理失败情况。关键点在于：只对可重试错误重试（如网络断连、超时），跳过服务端明确返回的业务错误（如 rpc: service 中携带的非临时错误）。
func (c *RetryRPCClient) Call(serviceMethod string, args interface{}, reply interface{}) error {
var lastErr error
for i := 0; i < c.maxRetries; i++ {
ctx, cancel := context.WithTimeout(context.Background(), c.callTimeout)
defer cancel()
// 注意：标准 net/rpc 不接受 context，所以需在 Call 后检查是否因超时被 cancel
done := make(chan error, 1)
go func() {
done <- c.client.Call(serviceMethod, args, reply)
}()
select {
case err := <-done:
if err == nil {
return nil
}
// 判断是否值得重试
if isTemporaryError(err) {
lastErr = err
time.Sleep(c.backoff(i))
continue
}
return err
case <-ctx.Done():
lastErr = ctx.Err()
if i == c.maxRetries-1 {
return lastErr
}
time.Sleep(c.backoff(i))
continue
}
}
return lastErr}
func isTemporaryError(err error) bool {
if err == nil {
return false
}
// 常见临时错误
if strings.Contains(err.Error(), "i/o timeout") ||
strings.Contains(err.Error(), "connection refused") ||
strings.Contains(err.Error(), "broken pipe") ||
strings.Contains(err.Error(), "use of closed network connection") {
return true
}
// 检查是否为 syscall.ECONNREFUSED 等底层临时错误
var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
return true
}
return false
}
替换底层传输层：用 http.Transport 封装 RPC over HTTP 并启用内置重试
如果你使用的是 net/rpc/jsonrpc 或自定义 HTTP handler 暴露 RPC 服务，可以把客户端换成 http.Client，利用其 Transport 的 MaxIdleConns、MaxIdleConnsPerHost 和自定义 RoundTrip 实现连接复用与失败重试。注意：这不适用于原生 tcp 协议的 net/rpc，必须走 HTTP。
-
http.Client本身不自动重试，但你可以包装RoundTrip—— 对5xx或连接级错误（如net.OpError）触发重试 - 避免对
POST请求无条件重试，需确保服务端方法是幂等的（例如不依赖递增 ID 或状态变更） - 重试间隔建议用指数退避：
time.Second ，最大不超过 10 秒 - 记得设置
Request.Body可重放（用bytes.NewReader包装原始 payload）
用第三方库 go-grpc-middleware？不，那是 gRPC —— 别混淆协议
很多开发者搜 “Go RPC retry” 会误入 gRPC 生态，但 gRPC 和 net/rpc 完全不同：前者是基于 HTTP/2 的现代 RPC 框架，后者是 Go 早期设计的简单 TCP/HTTP JSON/XML 二进制协议。如果你项目里用的是 net/rpc，引入 grpc-go 或 go-grpc-middleware 不仅无法工作，还会增加不必要的依赖和协议转换成本。
真正适配 net/rpc 的重试，只能靠自己封装调用逻辑或换用更现代的替代方案（如 twirp、kit 或直接迁移到 gRPC）。临时性网络抖动的容忍、服务发现、熔断这些能力，标准库从没打算提供——它只负责“把请求发出去，把响应读回来”。
