如何在Golang中实现错误重试机制_Golang错误重试与自动化控制

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语言免费学习笔记（深入）”；

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 } 
func BackoffDelay(base time.Duration, attempt int) time.Duration { d := time.Duration(math.Pow(2, float64(attempt)))  base if d > time.Second30 { 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 调用
• 日志里务必打印重试次数和原始错误，否则线上出现“数据重复”时根本无法回溯是否被重试触发

重试不是万能胶水，它掩盖不了设计缺陷。最常被跳过的一步，是在重试前确认：这个错误，真的是暂时性的吗？