RPC调用失败需先区分网络错误（如net.OpError）与服务端异常（如rp

c: server error或codes.Internal）；gRPC重试须配置MaxAttempts、PerCallTimeout和RetryableStatusCodes；错误应结构化携带code/message/details；熔断触发条件为时间窗口内失败率超阈值且请求数达标。

RPC调用失败时如何快速判断是网络问题还是服务端异常

Go 的 net/rpc 和主流框架（如 gRPC）在调用失败时返回的错误类型差异大，不能只靠 err != nil 做统一处理。关键看错误是否实现了 net.Error 接口或包含特定字符串（如 "connection refused"、"i/o timeout"），这类属于客户端可重试的瞬时故障；而像 "rpc: server error" 或 gRPC 的 codes.Internal 通常意味着服务端逻辑出错，重试无意义。

• 用 errors.As(err, &net.OpError{}) 判断是否为底层网络错误
• 对 gRPC，用 status.Code(err) 区分 codes.Unavailable（可重试）和 codes.NotFound（不可重试）
• 避免用 strings.Contains(err.Error(), "timeout")，因部分中间件会包装错误，推荐用标准接口断言

gRPC 中启用重试策略必须配置哪些字段

gRPC 客户端默认不重试，需显式配置 grpc.RetryPolicy 并通过 grpc.WithDefaultCallOptions 注入。仅设置 MaxAttempts 不生效，还必须指定 PerCallTimeout 和 RetryableStatusCodes，否则重试逻辑不会触发。

• MaxAttempts：最大尝试次数（含首次），建议 ≤ 3
• InitialBackoff 和 MaxBackoff 控制退避间隔，防止雪崩
• RetryableStatusCodes 至少包含 codes.Unavailable、codes.ResourceExhausted，排除 codes.InvalidArgument 等客户端错误
• 注意：服务端需开启 grpc.EnableTracing 才能透传重试上下文，否则每次重试都会生成新 traceID

自定义 RPC 错误码与业务错误解耦的关键点

直接把业务错误（如“余额不足”）塞进 error 字符串里，会导致客户端无法结构化识别。应统一用自定义错误类型实现 GRPCStatus() 方法（gRPC）或嵌入 rpc.ServerError（标准 net/rpc），让错误携带 code、message、details 三要素。

• gRPC 推荐用 status.New(codes.Code, msg).WithDetails(...) 构建可序列化错误
• 标准 RPC 可在返回结构体中增加 ErrorCode int 字段，而非依赖 error 字符串解析
• 切忌在错误信息里拼接敏感数据（如用户 ID、金额），日志记录时单独打点，RPC 返回体保持脱敏
• 客户端必须检查 ErrorCode 或 status.Code()，而不是 err.Error() 内容，否则升级后易断裂

熔断器（Circuit Breaker）在 Go RPC 中何时该触发

单纯靠重试不能应对持续性故障，必须引入熔断。触发条件不是“连续失败 N 次”，而是“单位时间窗口内失败率超过阈值 + 失败请求数达到最小采样量”。例如：60 秒内失败率 ≥ 50% 且至少有 20 次请求，才打开熔断器。

立即学习“go语言免费学习笔记（深入）”；

• 推荐用 sony/gobreaker，其 Settings.OnStateChange 可用于告警或降级通知
• 熔断打开后，所有新请求应立即返回预设降级响应（如缓存数据或空对象），不走网络
• 半开状态必须限制试探请求数（如只放行 1–2 个），避免恢复期压垮尚未稳定的下游
• 注意：gRPC 的流式 RPC（stream）不支持自动熔断，需在 handler 层手动控制

容错设计最常被忽略的是“降级响应的语义一致性”——比如订单查询接口熔断后返回空订单，但上游仍按成功流程走支付，这种错位比失败本身更危险。