Go标准库无time.Retry，需手动封装；必须支持context.Context、错误分类判断、指数退避，推荐20行内手写实现而非引入第三方依赖。
Go 中用 time.Retry？不存在的，得自己封装
Go 标准库没有 retry 或类似 time.Retry 的函数，所有重试逻辑必须手动控制。这不是缺陷，而是设计取舍：重试涉及错误判断、退避策略、上下文取消、最大尝试次数等多维度决策，硬编码进标准库反而会限制灵活性。
常见错误是直接写个 for 循环 + time.Sleep，但漏掉 context.Context 支持，导致超时或取消无法中断重试；或者把所有错误都重试，结果数据库连接失败也反复重试，加重服务压力。
- 必须显式传入
context.Context，用于支持超时、取消和 deadline 传播 - 重试前应先判断错误类型，例如
net.OpError可能可重试，而sql.ErrNoRows是业务正常结果，不应重试 - 避免固定间隔重试（如每次 sleep 100ms），优先使用指数退避（
backoff）降低下游冲击
用 backoff.Retry 还是手写 for-loop？推荐轻量手写
第三方库如 github.com/cenkalti/backoff/v4 提供了完整的重试封装，但引入依赖只为一个重试逻辑，往往得不偿失。多数场景下，20 行以内的手写实现更可控、更易调试。
以下是一个生产可用的最小重试模板：
立即学习“go语言免费学习笔记（深入）”；
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
func DoWithRetry(ctx context.Context, fn func() error, maxRetries int, baseDelay time.Duration) error {
var err error
for i := 0; i <= maxRetries; i++ {
err = fn()
if err == nil {
return nil
}
if i == maxRetries {
break
}
select {
case <-time.After(BackoffDelay(baseDelay, i)):
case <-ctx.Done():
return ctx.Err()
}
}
return err
}
<p>func BackoffDelay(base time.Duration, attempt int) time.Duration {
d := time.Duration(math.Pow(2, float64(attempt))) <em> base
if d > time.Second</em>30 {
d = time.Second * 30
}
return d
}-
fn必须是无参函数，便于隔离每次重试的执行环境（比如新建 HTTP client、重连 DB） -
BackoffDelay实现简单指数退避，第 0 次不延迟，第 1 次延迟base，第 2 次延迟base*2，依此类推，上限 30 秒 - 每次重试前都检查
ctx.Done()，确保不会在取消后继续跑
HTTP 请求重试要特别处理状态码和 body
对 http.Client.Do 做重试时，不能只看 error != nil。很多错误（如 net/http: request canceled、i/o timeout）可重试，但 4xx 错误中只有部分（如 429 Too Many Requests）适合重试，5xx 通常可以，而 401/403/404 属于客户端问题，重试无意义。
更要命的是：HTTP 请求体（req.Body）是一次性读取的，重试时若没重置，第二次 Do 会报 body closed 或空请求体。
- 务必在每次重试前重建
*http.Request，或使用bytes.NewReader包装原始 payload - 检查响应状态码：
resp.StatusCode >= 500 || resp.StatusCode == 429才考虑重试 - 调用
resp.Body.Close()后再进入下次循环，否则可能泄漏文件描述符 - 如果用了自定义
http.Transport，确认MaxIdleConnsPerHost足够，否则高并发重试会卡在连接池
DB 查询重试容易忽略事务与幂等性
对数据库操作加重试，比 HTTP 更危险。一次 INSERT 重试两次，可能插入两条重复记录；事务中重试某一步，可能破坏原子性。
真正安全的 DB 重试，只适用于明确可重试的场景：连接中断、锁等待超时（ERROR: lock not available）、临时死锁（PostgreSQL 的 deadlock_detected）。
- 不要对
UPDATE/DELETE无条件重试，除非 SQL 本身带WHERE条件且业务上允许“最多执行一次”语义 - 使用
SELECT ... FOR UPDATE前，先确认隔离级别和锁行为，重试可能加剧锁竞争 - 如果底层 driver 支持（如
pgx），优先用其内置重试配置（如pgx.ConnConfig.MaxRetries），而非包裹整个Exec调用 - 日志里务必打印重试次数和原始错误，否则线上出现“数据重复”时根本无法回溯是否被重试触发
重试不是万能胶水，它掩盖不了设计缺陷。最常被跳过的一步，是在重试前确认：这个错误，真的是暂时性的吗？
