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() 容易漏判或误判。

实操建议：

• 对 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）。重试只应针对临时性故障（网络抖动、服务瞬时过载、连接中断）。

实操建议：

• 仅对明确可重试的错误码重试：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 超时，进一步压缩可用时间。

实操建议：

• 每次 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 已关闭，无法继续复用。

实操建议：

• 流式调用中，每个 Send() 和 Recv() 都必须单独检查 err，不能只在最后检查
• 流式调用一般不支持“断点续传”式重试；若需可靠性，应在业务层设计幂等消息 ID + 服务端去重，而非依赖重试 stream
• 对服务器流（server streaming），一旦 Recv() 出错，应立即退出循环并关闭 stream；不要尝试在错误后继续 Recv()

真正难处理的，是那些看似可重试、但重试后行为不一致的情况——比如上游服务未实现幂等，或者重试触发了重复扣款。这类问题无法靠客户端重试逻辑解决，必须推动服务端补全幂等键和状态机校验。