RPC调用失败需先区分网络错误（如net.OpError）与服务端异常（如rpc: 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 层手动控制
容错设计最常被忽略的是“降级响应的语义一致性”——比如订单查询接口熔断后返回空订单，但上游仍按成功流程走支付，这种错位比失败本身更危险。
