Go net/rpc 默认不支持重试，需手动封装 Call 方法实现带指数退避、错误过滤和连接管理的安全重试，生产环境建议迁移到 gRPC 或 Kitex。
Go net/rpc 默认不支持重试，必须手动封装
Go 标准库的 net/rpc（包括 jsonrpc 和 gob 编码）本身是无状态、无重试逻辑的。每次调用对应一次底层连接写入 + 读取响应，失败就直接返回错误，不会自动重连或重发。这意味着：网络抖动、服务短暂不可用、TCP 连接被对端静默关闭等情况，都会导致 client.Call() 立即失败，而你拿到的只是类似 read tcp 127.0.0.1:54321->127.0.0.1:8080: i/o timeout 或 connection refused 这样的底层错误。
所以重试必须由调用方自己控制——不是改服务端，也不是换框架，而是包装 *rpc.Client 的 Call 方法。
用带指数退避的循环 + 可重试错误判断实现安全重试
简单 for 循环重试容易打爆服务或客户端资源，必须加入延迟和错误过滤。关键点有三个：哪些错误值得重试、每次延迟多久、最多试几次。
-
io.EOF、io.ErrUnexpectedEOF、net.OpError中的timeout和connection refused通常可重试；rpc.ServerError（比如服务端 panic 返回的字符串错误）一般不可重试 - 使用指数退避（exponential backoff），例如从 100ms 开始，每次 ×1.5，上限设为 1s，避免雪崩
- 最大重试次数建议设为 3～5 次，再高意义不大，且可能掩盖真实故障
func RetryCall(client *rpc.Client, serviceMethod string, args interface{}, reply interface{}) error {
var err error
maxRetries := 3
baseDelay := 100 * time.Millisecond
<pre class='brush:php;toolbar:false;'>for i := 0; i <= maxRetries; i++ {
err = client.Call(serviceMethod, args, reply)
if err == nil {
return nil
}
if !isRetryableError(err) {
return err
}
if i < maxRetries {
time.Sleep(baseDelay)
baseDelay = time.Duration(float64(baseDelay) * 1.5)
}
}
return err}
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
func isRetryableError(err error) bool { if err == io.EOF || err == io.ErrUnexpectedEOF { return true } if opErr, ok := err.(*net.OpError); ok { if opErr.Err != nil { if strings.Contains(opErr.Err.Error(), "timeout") || strings.Contains(opErr.Err.Error(), "connection refused") || strings.Contains(opErr.Err.Error(), "broken pipe") { return true } } } return false }
HTTP-based RPC（如 net/rpc/jsonrpc）需注意连接复用与状态清理
如果用的是 jsonrpc，底层走的是 HTTP，而 Go 的 http.Transport 默认复用连接。但 net/rpc 不管理它，多次重试可能复用一个已失效的连接（比如服务端重启后 TCP 连接还留在 TIME_WAIT 状态），导致后续请求持续失败。这时不能只靠重试，还得主动刷新连接。
- 每次重试前，调用
client.Close()再重建*rpc.Client（适合低频调用） - 或者更轻量：强制关闭底层 HTTP 连接，通过反射访问
client的未导出字段conn并调用Close()（不推荐，脆弱） - 更稳妥的做法是改用长连接池管理，比如用
gorilla/rpc或自建基于http.RoundTripper的重试 transport
简而言之：HTTP RPC 的重试比 raw TCP 更容易卡在“假连接”上，必须配合连接生命周期控制。
生产环境建议直接迁移到 gRPC 或 Kitex，标准 net/rpc 已不适用复杂容错场景
标准库 net/rpc 缺少中间件、超时传递、上下文取消、负载均衡、熔断等能力。即使你补全了重试，也很难优雅处理：重试期间上下文已取消、重试中服务彻底不可用需快速失败、不同方法需要不同重试策略等问题。
如果你正在设计新服务或重构旧系统：
- 用
gRPC+grpc-go的retry.Interceptor，支持 per-RPC 配置、状态码过滤、抖动退避 - 用字节开源的
Kitex，内置重试、熔断、降级，且兼容 Thrift/Protobuf - 若必须坚持
net/rpc，至少把重试逻辑抽成独立 package，统一管控重试策略、指标上报和日志标记
重试本身不难写，难的是它和超时、取消、监控、服务发现搅在一起之后，边界开始模糊——这时候继续硬刚标准库，不如承认它已不是现代微服务的合适载体。
