RPC调用失败时应区分错误类型并精准重试：net/rpc用*rpc.Error判断Code，gRPC须用status.FromError()解包再判Code；仅对codes.Unavailable等临时性错误按指数退避重试≤3次。
RPC调用失败时，err 通常不是 nil，但具体类型容易被忽略
Go 标准库的 net/rpc 和主流 gRPC（google.golang.org/grpc）在出错时都返回非 nil 的 error，但它们的底层类型完全不同：net/rpc 返回的是 *rpc.Error（含 Code、Msg 字段），而 gRPC 返回的是 *status.Status（需用 status.FromError() 解包）。直接用 errors.Is(err, xxx) 或字符串匹配 err.Error() 容易漏判或误判。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 对
net/rpc：检查err是否为*rpc.Error，再判断Code是否为rpc.ErrShutdown或自定义错误码 - 对 gRPC：必须先调用
status.FromError(err)，再用.Code()判断是否为codes.Unavailable、codes.DeadlineExceeded等可重试状态 - 避免用
strings.Contains(err.Error(), "timeout")—— gRPC 的超时错误信息可能不含 “timeout” 字样，且不同版本输出不一致
重试逻辑不能无条件套用 for + time.Sleep
简单循环重试会掩盖真实问题，比如服务端永久性错误（如参数校验失败、权限不足）或客户端配置错误（如错误的 endpoint）。重试只应针对临时性故障（网络抖动、服务瞬时过载、连接中断）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 仅对明确可重试的错误码重试：
codes.Unavailable、codes.ResourceExhausted（限流）、codes.Internal（部分场景）、codes.Unknown（谨慎） - 跳过不可重试错误：
codes.InvalidArgument、codes.PermissionDenied、codes.NotFound、codes.AlreadyExists - 使用指数退避（exponential backoff），而非固定间隔；起始延迟建议 100ms，最大不超过 2s，总重试次数建议 ≤ 3 次
func callWithRetry(client MyServiceClient, ctx context.Context, req *Request) (*Response, error) {
var resp *Response
var err error
backoff := 100 * time.Millisecond
for i := 0; i < 3; i++ {
resp, err = client.DoSomething(ctx, req)
if err == nil {
return resp, nil
}
s, ok := status.FromError(err)
if !ok || !isRetryable(s.Code()) {
return nil, err
}
if i < 2 { // 不在最后一次迭代后 sleep
time.Sleep(backoff)
backoff *= 2
}
}
return resp, err
}
context.Context 超时与重试必须协同设计
常见错误是给整个重试过程设一个长 context.WithTimeout（如 30s），再在里面做 3 次各 5s 的 RPC 调用——这会导致最后一次调用可能只剩不到 1s 超时时间，还没发出去就被 cancel。更糟的是，重试中间的 time.Sleep 也计入 context 超时，进一步压缩可用时间。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次 RPC 调用都单独带子 context：
ctx, cancel := context.WithTimeout(parentCtx, singleCallTimeout) - 重试总耗时由外层逻辑控制（如计时器或重试次数），而非依赖单个 context 的 deadline
- 若使用
golang.org/x/time/rate或类似限流器，注意它不感知 context 取消，需手动结合select检查ctx.Done()
gRPC 流式 RPC 的错误处理和重试更复杂
Unary RPC 错误发生在一次调用结束时，而 streaming RPC（如 ClientStream）可能在 Send()、Recv() 或 CloseAndRecv() 任意环节出错，且错误后 stream 已关闭，无法继续复用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 流式调用中，每个
Send()和Recv()都必须单独检查err，不能只在最后检查 - 流式调用一般不支持“断点续传”式重试；若需可靠性，应在业务层设计幂等消息 ID + 服务端去重，而非依赖重试 stream
- 对服务器流（server streaming），一旦
Recv()出错，应立即退出循环并关闭 stream；不要尝试在错误后继续Recv()
真正难处理的，是那些看似可重试、但重试后行为不一致的情况——比如上游服务未实现幂等，或者重试触发了重复扣款。这类问题无法靠客户端重试逻辑解决，必须推动服务端补全幂等键和状态机校验。
