go 的 net/rpc 默认不支持超时和重试，需手动封装超时、错误分类及指数退避；可通过 goroutine + channel + select 模拟 context 控制的带超时调用，如用 context.WithTimeout 启动异步 RPC 并监听 done 通道。
Go 的 net/rpc 默认不支持超时和重试，直接调用 Call 或 Go 会永久阻塞，直到服务端响应或连接异常。要实现可靠的 RPC 容错，需手动封装超时控制、错误分类、指数退避重试等逻辑。
使用 context 控制单次 RPC 调用超时
Go 标准库的 net/rpc 不接收 context.Context，但可通过启动 goroutine + channel + select 模拟带超时的调用。核心思路是：发起 RPC 异步调用，同时监听超时通道，任一完成即返回。
- 创建带超时的
context.WithTimeout，但仅用于控制 goroutine 生命周期，不传入 RPC 方法 - 用
make(chan *rpc.Call, 1)接收回调结果（Go方式）或同步等待（Call+ 单独 goroutine） -
select等待结果或超时，超时后主动关闭连接（可选），避免资源滞留
示例关键片段：
client := rpc.NewClient(conn)
done := make(chan *rpc.Call, 1)
ctx, cancel := context.WithTimeout(context.background(), 3*time.Second)
defer cancel()
go func() {
call := client.Go(“Arith.Multiply”, args, &reply, nil)
done }()
select {
case return errors.New(“rpc timeout”)
case call := if call.Error != nil {
return call.Error
}
return nil
}
识别可重试错误并设计重试策略
不是所有错误都适合重试。应区分网络层错误（如连接拒绝、I/O timeout）、服务端业务错误（如参数校验失败）和临时性错误（如服务端过载 503）。建议只对以下情况重试：
立即学习“go语言免费学习笔记（深入）”；
- 底层连接错误：
net.OpError、io.EOF、syscall.ECONNREFUSED - RPC 协议层超时：
rpc.ErrShutdown、自定义的 “server busy” 错误码 - 明确返回 HTTP 状态码 429 / 503（若基于 HTTP 封装 RPC）
避免重试：json.UnmarshalError、服务端返回的 InvalidArgument、NotFound 等语义明确的失败。
实现带退避的有限重试封装
简单 for 循环重试易打爆服务，推荐使用指数退避（exponential backoff）+ 最大尝试次数。可借助 github.com/cenkalti/backoff/v4，也可手写轻量版：
- 初始延迟 100ms，每次翻倍，上限设为 1s（防止长尾累积）
- 最多重试 3 次（含首次），即总共最多发起 4 次请求
- 每次重试前检查是否已取消（配合 context）；重试间 sleep 前先
select判断 ctx 是否 Done - 连接复用时，失败后应新建连接（旧连接可能处于半开状态）
注意：重试必须保证幂等性。RPC 方法应设计为幂等（如查询、更新 with version），或由客户端生成唯一 request ID 配合服务端去重。
结合连接池与健康检查提升可用性
单连接故障会导致后续全部请求失败。生产环境建议：
- 维护多个后端连接（如轮询或随机选取），失败时快速切换节点
- 对每个连接做简易健康探测（如定期发空 ping 请求），剔除不可用连接
- 使用连接池（如
github.com/hashicorp/go-retryablehttp思路改造 RPC client）管理连接生命周期
若使用 gRPC 替代原生 net/rpc，可直接启用内置的 WithBlock、WithTimeout、WithKeepaliveParams 及 grpc_retry 中间件，大幅降低容错开发成本。
基本上就这些。超时和重试不是加个 for 和 time.Sleep 就完事，关键是分清错误类型、控制退避节奏、保障幂等、及时清理坏连接。小项目手写够用，中大型系统建议迁移到 gRPC 或用成熟 RPC 框架。