最可控的Go HTTP客户端重试方案是自定义RoundTripper配合http.Client，重点判断值得重试的错误类型：网络超时、连接拒绝、5xx响应；避免对4xx（如400）和健康检查等请求盲目重试。
Go HTTP客户端重试：用http.Client配合自定义RoundTripper最可控
直接改http.Client.Transport是主流做法，比在业务层反复for循环更干净。关键不是“重试几次”，而是“哪些错误值得重试”——网络超时、连接拒绝、5xx服务端错误通常可重试，4xx（如400 Bad Request）基本不该重试。
常见错误：把http.DefaultClient直接拿来复用并全局加重试逻辑，结果所有HTTP调用都带上重试，连健康检查请求也重试三次，反而放大下游压力。
- 用
&http.Transport{}包装原生RoundTripper，只拦截RoundTrip返回的错误 - 对
url.Error类型判断：err.Timeout()或strings.Contains(err.Error(), "connection refused") - 对HTTP响应码判断：仅当
resp.StatusCode >= 500 && resp.StatusCode 才考虑重试 - 每次重试前用
time.Sleep做指数退避，例如time.Second * (1
gRPC Go客户端重试：依赖grpc.WithRetry但需手动启用
gRPC官方从v1.29+才正式支持客户端重试，且默认关闭。不显式配置grpc.WithRetry，哪怕服务端返回Unavailable也不会重试。
容易踩的坑：以为设置了grpc.WithTimeout就自动带重试，其实完全无关；或者只配了grpc_retry.WithMax(3)却漏掉grpc_retry.WithPerRPCCredentials等必要选项，导致重试逻辑根本没加载。
立即学习“go语言免费学习笔记（深入）”；
- 必须传入
grpc.DialOption：如grpc.WithTransportCredentials(insecure.NewCredentials())之后追加grpc.WithChainUnaryInterceptor(grpc_retry.UnaryClientInterceptor(...)) - 重试条件由
grpc_retry.WithCodes(codes.Unavailable, codes.ResourceExhausted)控制，不包含codes.NotFound或codes.InvalidArgument - 注意gRPC重试会重新序列化请求体，所以
proto.Message必须可重复编码，避免含sync.Mutex等不可序列化字段
微服务间调用重试：别只靠客户端，要和服务端幂等性对齐
重试机制本身不解决数据重复问题。比如转账接口被重试两次，服务端没做幂等校验，就会扣两次款。
实际落地时，90%的重试问题最后都卡在服务端没提供idempotency-key或request_id去查重。客户端再怎么指数退避、熔断降级，只要后端不认这个key，重试就是危险操作。
- HTTP场景：客户端在Header里带
X-Idempotency-Key: uuid，服务端用Redis存该key的响应结果（带TTL） - gRPC场景：在
Requestmessage里增加string idempotency_key = 1;字段，并在服务端方法开头校验 - 重试间隔不能太短（如100ms），否则可能还没来得及写入幂等缓存就被下一次请求击中空缓存
第三方库选型：优先用backoff/v4而非自己手写退避逻辑
github.com/cenkalti/backoff/v4是Go生态事实标准，支持Jitter、上下文取消、重试事件钩子，比抄一段time.Sleep(time.Second * (1 可靠得多。
典型误用：把backoff.Retry直接套在http.Post上，却没处理请求体的io.ReadCloser重用问题——HTTP Body只能读一次，第二次重试时Body已EOF。
- 对含Body的请求，每次重试前必须重新构造
*http.Request，不能复用原req.Body - 用
backoff.WithContext(ctx, b)确保超时或取消时立即退出，而不是硬等完所有重试次数 - 若需记录每次重试原因，用
backoff.WithNotify(func(err error, d time.Duration) {...})
重试不是加个for循环就完事，它和超时、熔断、幂等是咬合在一起的齿轮。少装一个，整个链路就可能崩出意料之外的副作用。
