RPC调用失败时盲目重试会引发雪崩，必须结合超时、退避、熔断三要素；net/rpc需手动封装context超时，推荐迁移到原生支持context的gRPC，并通过拦截器统一实现带错误过滤与指数退避的重试逻辑。
RPC调用失败时直接重试会放大问题
Go 标准库 net/rpc 本身不提供重试机制，强行在客户端套一层 for 循环重试 Call 或 Go，往往导致雪崩：服务端超时未返回，客户端反复发请求，堆积更多连接和 goroutine。重试必须配合超时、退避、熔断三要素，否则不是容错，是攻击。
- 默认
rpc.Client的底层连接是长连接，但单次Call调用没有内置超时 —— 必须手动包装context.WithTimeout或改用支持 context 的 RPC 框架（如 gRPC） - 网络抖动时连续重试 3 次，不如等 100ms 后再试（指数退避），避免瞬时重试洪峰
- 若后端服务已全量 503，继续重试毫无意义；需结合错误类型判断是否可重试：
io.EOF、net.OpError（连接拒绝/超时）可重试；rpc.ErrShutdown或明确的业务错误码（如"user_not_found"）不应重试
用 context 控制单次调用生命周期是重试前提
标准 net/rpc 的 Client.Call 签名不接受 context.Context，所以无法直接中断挂起的调用。可行方案只有两个：换框架，或自己封装带超时的调用逻辑。
- 推荐迁移到
gRPC：原生支持context.Context，且grpc.WithBlock()+context.WithTimeout()可精确控制每次请求生命周期 - 若必须用
net/rpc，需在 dial 阶段设置连接超时，并用time.AfterFunc+sync.Once手动 cancel goroutine（不完美，但比无超时强） - 示例伪代码：启动 goroutine 调用
client.Call，同时select等待ctx.Done()或结果 channel；一旦超时，关闭 channel 并标记本次失败
简单可靠的重试封装：backoff + error filter
重试逻辑不该散落在每个 Call 前后，应抽成可复用函数。关键点是区分“可重试错误”和“不可重试错误”，并控制退避间隔。
- 使用
github.com/cenkalti/backoff/v4库，配置MaxRetries: 3、InitialInterval: 100 * time.Millisecond - 定义重试判定函数：
func isRetryable(err error) bool { return errors.Is(err, io.EOF) || strings.Contains(err.Error(), "connection refused") || strings.Contains(err.Error(), "i/o timeout") } - 不要重试 HTTP 状态码类错误（
rpc不暴露 status，但自定义错误字符串里含"400"或"500"就该跳过） - 每次重试前检查
ctx.Err() != nil，防止重试过程本身被取消后还继续
gRPC 场景下更推荐用拦截器统一处理重试
如果你已在用 gRPC，别自己写重试循环 —— 利用 UnaryClientInterceptor 在拦截器里做重试，对业务代码零侵入。
立即学习“go语言免费学习笔记（深入）”；
- 拦截器内用
backoff.Retry包裹原始invoker调用，传入自定义重试策略和错误判定函数 - 注意：gRPC 默认对非幂等方法（如 POST /update）禁用重试，需显式设置
grpc_retry.WithPerRetryTimeout和grpc_retry.WithCodes(codes.Unavailable, codes.DeadlineExceeded) - 重试日志必须打全：第几次、退避多久、原始错误、是否最终成功 —— 否则线上出问题根本没法定位是重试掩盖了真实故障还是加重了负载
重试不是加个 for 循环就完事；真正难的是判断“此刻该不该重”，以及“重了之后系统整体会不会更糟”。很多 RPC 失败本质是下游已不可用，这时候最稳妥的操作，往往是立刻失败、上报告警，而不是默默 retry 到超时。
