处理并发任务失败重试需控制次数、避免雪崩、区分瞬态与永久性错误，使用指数退避加抖动策略，结合 context 控制生命周期，3～5 次重试为宜，仅对网络超时、503 等可重试错误生效，400、404 等应直接失败。
Go 语言中处理并发任务失败后的重试，核心在于：控制重试次数、避免雪崩、区分可重试错误、隔离任务状态。不是所有错误都该重试，也不是重试越多越好。
明确哪些错误值得重试
网络超时、临时性 HTTP 503、数据库连接中断等属于“瞬态错误”，适合重试；而 400 Bad Request、404 Not Found、JSON 解析失败等属于“永久性错误”，重试无意义，应直接失败并记录。
- 用自定义错误类型或错误包装（errors.Is / errors.As）判断错误本质
- HTTP 场景下可检查 err != nil && resp == nil（连接级失败）或 resp.StatusCode >= 500
- 数据库操作中，检测如 driver.ErrBadConn、sql.ErrNoRows（注意：后者通常不重试）
用带退避的重试策略代替固定间隔
连续快速重试可能加剧下游压力。推荐使用指数退避（exponential backoff），例如从 100ms 开始，每次翻倍，加上随机抖动（jitter）防共振。
- 可用 github.com/cenkalti/backoff/v4 库，简洁封装了常用策略
- 手动实现时，每次 sleep 时间 = base × 2^attempt + jitter（jitter 建议为 0–base 毫秒随机值）
- 最大重试次数建议设为 3～5 次，超时总时间建议 ≤ 单任务原始超时的 2～3 倍
在并发任务中安全集成重试逻辑
goroutine 中直接循环重试容易失控（如死循环、goroutine 泄漏）。应把重试封装成独立函数，并配合上下文控制生命周期。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 每个任务使用独立 context.WithTimeout 或 context.WithDeadline，确保整体不超时
- 重试函数接收 context.Context，每次重试前先 select { case
- 避免在 for select 外层套 for 循环重试，应把重试逻辑内聚在单个函数里，返回最终结果或错误
- 若用 errgroup 启动多个并发任务，每个子任务内部自行处理重试，不要让重试影响其他 goroutine
记录与可观测性不能少
重试本身是异常路径，必须留痕，否则问题难定位。
- 首次失败、每次重试、最终成功/失败，都应打日志，标注 attempt=1/2/3 和耗时
- 关键字段如 task_id、url、req_id 保持贯穿，方便链路追踪
- 统计指标如 retry_count_total、retry_succeeded_ratio 推荐用 Prometheus 上报
- 对高频重试的任务，可加告警（如 5 分钟内某接口重试率 > 20%）
基本上就这些。重试不是兜底万能药，而是有边界的容错手段。设计时想清楚“为什么重试”“重试几次”“重试会不会更糟”，比堆代码更重要。
