网络抖动需通过分层超时、可重试错误精准识别和指数退避协同解决；盲目业务层for循环重试会放大问题，应使用自定义roundtripper封装http.transport，避免复用defaultclient及全局重试。
直接上结论：网络抖动不是靠“多试几次”解决的，而是靠「分层超时 + 可重试错误精准识别 + 指数退避」三者咬合。盲目在业务层写 for 循环重试，反而会放大抖动影响。
HTTP 客户端该用自定义 RoundTripper 还是业务层 for 循环
用 http.Transport 包装原生 RoundTripper 是更干净、更可控的做法。业务层写 for 循环容易把超时、错误分类、退避逻辑和业务代码混在一起，后续加监控或换策略就得动业务函数。
- 别复用
http.DefaultClient并全局加重试逻辑——健康检查请求也会被重试三次，反而放大下游压力 - 只拦截
RoundTrip返回的错误，避免污染其他 HTTP 调用（比如静态资源、指标上报） - 对
url.Error类型判断：优先用err.Timeout()，而非strings.Contains(err.Error(), "timeout")；连接拒绝类错误用errors.Is(err, syscall.ECONNREFUSED)更可靠 - 响应码判断必须严格：仅当
resp.StatusCode >= 500 && resp.StatusCode 才考虑重试，<code>429和408可选，但400/401/404绝对不重试
gRPC 客户端重试为什么配置了还不生效
gRPC 官方从 v1.29+ 才正式支持客户端重试，且默认关闭。光配 grpc.WithTimeout 或 grpc_retry.WithMax(3) 都没用，必须同时满足三个条件：
- 显式传入
grpc.WithChainUnaryInterceptor(grpc_retry.UnaryClientInterceptor()) - 在
grpc.DialOption中正确拼接——grpc.WithTransportCredentials()后追加重试拦截器，顺序错就失效 - 用
grpc_retry.WithCodes(codes.Unavailable, codes.ResourceExhausted)明确指定可重试码；codes.NotFound和codes.InvalidArgument不会触发重试 - proto 文件中对应 method 必须声明
retryable: true，否则服务端不返回可重试 header
context 超时后还能不能重试？怎么避免 goroutine 泄漏
能重试，但每次重试必须新建 context.WithTimeout 或 context.WithDeadline，绝不能复用已 cancel() 的 ctx。否则第二次进循环时 ctx.Err() 已是 context.Canceled，重试变成空转，还可能泄漏 goroutine。
- 每次重试前先检查
ctx.Err() != nil，为真就立即返回，不进下一次循环 -
cancel()必须显式调用，尤其在循环内——defer cancel()会导致第一次重试后cancel()就执行，后续所有重试都拿不到有效 context - gRPC 调用超时必须通过
context控制，grpc.Dial()中的grpc.WithTimeout已被弃用且不生效
用 backoff/v4 还是手写重试逻辑
推荐直接用 github.com/cenkalti/backoff/v4，而不是手写 for + time.Sleep。手写容易忽略 jitter、context 中断、错误包装等关键点。
- 自己封装重试时，常见疏漏是未将原始 error 包装进重试判断逻辑，导致网络超时和业务错误混在一起重试
- 重试次数硬编码在循环里，无法动态调整或按错误类型分级（比如连接失败重试 3 次，认证失败直接失败）
-
backoff.Retry自动处理指数退避、jitter、ctx.Done()中断，只需传入一个闭包函数 - 注意：重试函数内每次调用都要重建请求对象（如
http.Request或 proto message），含sync.Mutex等不可序列化字段会导致 panic
最易被忽略的点是服务端幂等性——没有幂等保证的重试，比不重试还危险。哪怕客户端逻辑再严谨，只要服务端一次写操作被重复执行，数据就错了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
