日常 http/grpc 调用优先用 retry.do；需精细控制退避状态才选 backoff.retry。retry.do 开箱即用，封装完整；backoff.retry 更底层但需手动管理实例与上下文，共享会错乱 attempt 计数。
用 backoff.Retry 还是 retry.Do？选库前先看控制粒度
直接结论：日常 HTTP/gRPC 调用优先用 github.com/avast/retry-go 的 retry.Do；需要精细控制退避状态（比如复用单个 backoff 实例做流控）才选 github.com/cenkalti/backoff/v4 的 backoff.Retry。
原因很简单：retry.Do 把次数、延迟、错误过滤、上下文取消全包进一个函数调用里，写三行就跑起来；而 backoff.Retry 需要你手动构造 backoff.BackOff 实例、处理重置、包装 context，一不小心就漏掉 backoff.Reset() 或传错 ctx。
-
retry.Do默认带 jitter、自动限最大延迟、支持retry.RetryIf做类型判断，开箱即用 -
backoff.Retry更底层，适合嵌入 transport 层或自定义策略（比如按错误码动态调公比），但每个请求必须新建独立实例，共享会错乱 attempt 计数 - 别混用：
retry.Do里再套backoff.Retry是冗余的，两者都封装了退避逻辑
为什么 context.DeadlineExceeded 后还在重试？超时分层没做对
这不是 bug，是超时没分层——外层总 deadline 和内层单次请求 timeout 混在一起了。结果第一次请求还没返回，整个 context 就被 cancel，但重试逻辑还在 sleep 等下一次，白等。
正确做法是嵌套 context：
- 外层用
context.WithTimeout(context.Background(), 5*time.Second)控制“最多花多久重试完” - 每次调
http.Do前，用req.WithContext(context.WithTimeout(ctx, 800*time.Millisecond))单独设本次请求上限 - 退避等待时间只占单次 timeout 的一部分，比如 base=100ms，三次重试总退避约 700ms，留出余量防调度延迟
示例关键点：retry.Context(ctx) 必须传给 retry.Do，否则它根本感知不到 cancel；而 http.Client.Timeout 是全局兜底，不能替代 per-request timeout。
ShouldRetry 怎么写？别靠字符串匹配错误信息
用 strings.Contains(err.Error(), "timeout") 或正则匹配状态码，上线后大概率失效——错误文案随 Go 版本、服务端响应变，中文环境还 panic。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
应该用类型断言和标准错误判断：
- 网络错误：
errors.As(err, &net.OpError{}) && (netErr.Timeout() || netErr.Temporary()) - HTTP 5xx：
resp.StatusCode >= 500 && resp.StatusCode （注意先读 body 再 close） - gRPC 错误：
status.Code(err) == codes.Unavailable || status.Code(err) == codes.ResourceExhausted - 明确不重试：
errors.Is(err, sql.ErrNoRows)、errors.Is(err, context.DeadlineExceeded)（这是上层超时，不是可恢复错误）
4xx 中只有 429 Too Many Requests 和 408 Request Timeout 可考虑重试，其他一律跳过——重试 400 不会让服务变好，只会加重日志噪音。
并发重试为啥压垮下游？抖动（jitter）不是可选项
纯指数退避（100ms → 200ms → 400ms）在高并发下必然导致“重试风暴”：成千上万请求在同一毫秒发起重试，下游瞬间被打满。
加 jitter 是工业级标配，不是“锦上添花”：
-
retry.DelayType(retry.RandomDelay)或手算base * (2^attempt) * (0.5 + rand.Float64()*0.5) - 别用全局
rand：并发 goroutine 会竞态修改 seed，改用rand.New(rand.NewSource(time.Now().UnixNano())) - 硬设上限：
retry.MaxDelay(3*time.Second)，避免某次退避卡住几秒拖慢整体 SLA
最容易被忽略的一点：每个请求的退避状态必须隔离。用同一个 backoff.BackOff 实例供多个 goroutine 调 NextBackOff()，attempt 计数器会乱，间隔完全不可控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
