如何使用Golang实现并发任务重试_Golang goroutine错误处理与重试实践

不会，未被recover捕获的panic仅终止当前goroutine；须在每个goroutine入口用defer+recover兜底，不可跨goroutine捕获；重试应结合context与select避免泄漏和卡死。

goroutine 中 panic 会导致整个程序崩溃吗

不会，但默认不捕获就会向上抛出到 goroutine 起始函数，最终被 runtime.Goexit 终止该 goroutine，不波及主线程或其他 goroutine。关键点在于：未被 recover 捕获的 panic 仅杀死当前 goroutine。

常见错误是以为启动了 goroutine 就“自动兜底”，结果 http handler 或定时任务里 panic 后任务静默消失，日志里只有一行 panic: xxx 而无堆栈——因为没在 goroutine 内部做 defer + recover。

• 必须在每个独立 goroutine 的入口函数最外层加 defer func() { if r := recover(); r != nil { log.printf("goroutine panic: %v", r) } }()
• 不要在外部统一 recover：goroutine 是并发执行单元，无法跨 goroutine 捕获 panic
• recover 只在 defer 函数中有效，且仅对同 goroutine 的 panic 生效

用 channel 控制重试次数和超时的典型结构

直接用 for + time.After 做重试容易失控：比如每次重试都新建 timer，旧 timer 不 stop 会泄漏；或没考虑上下文取消，导致 goroutine 卡死。

推荐用 context.Context 配合 time.AfterFunc 或 select 多路复用，把重试逻辑封装成可取消、可超时的循环。

立即学习“go语言免费学习笔记（深入）”；

func doWithRetry(ctx context.Context, fn func() Error, maxRetries int, baseDelay time.Duration) error {     var err error     for i := 0; i <= maxRetries; i++ {         select {         case <-ctx.Done():             return ctx.Err()         default:         } 
    err = fn()     if err == nil {         return nil     }      if i == maxRetries {         break     }      delay := time.Duration(float64(baseDelay) * math.Pow(2, float64(i)))     select {     case <-time.After(delay):     case <-ctx.Done():         return ctx.Err()     } } return err
}

每次重试前检查 ctx.Done()，避免无效执行
指数退避用 math.Pow 计算，注意 float64 转 time.Duration 时截断风险（建议加 time.Microsecond 级别最小值保护）
不用 timer.Reset：goroutine 场景下每次重试都是新延迟，直接 time.After 更清晰安全

并发任务失败后如何统一收集错误而不阻塞
多个 goroutine 并发执行任务，部分失败时，如果用 sync.WaitGroup + 全局 error 变量，会面临竞态；若用 errgroup.Group，默认是“任一失败即返回”，不满足“全部执行完再汇总”的需求。
正确做法是让每个 goroutine 把结果（成功/失败+error）发到同一个 chan error，主 goroutine 收集并判断阈值。
results := make(chan error, numTasks) for i := 0; i < numTasks; i++ {     go func(taskID int) {         defer func() {             if r := recover(); r != nil {                 results <- fmt.errorf("panic in task %d: %v", taskid, r) } }() err := doWithRetry(context.Background(), func() error { return callexternalapi(taskid) }, 3, time.second) results <- }(i) 
var failedCount int for i := 0; i < numTasks; i++ { if err := <-results; err != nil { log.Printf("task failed: %v", err) failedCount++ } } if failedCount > 0 { return fmt.Errorf("failed %d of %d tasks", failedCount, numTasks) }

channel 缓冲区大小设为 numTasks，避免 sender 阻塞
每个 goroutine 自己 recover，防止 panic 导致结果 channel 发送失败
不要用 range results：goroutine 数量固定，用计数更可靠

重试逻辑里要不要重置 HTTP client 或数据库连接
不需要，也不应该。HTTP client 和 db/sql.DB 本身是并发安全、带连接池的长期对象，重试时复用它们反而能复用 TCP 连接、减少握手开销。问题常出在错误地每次重试都新建 client：

新建 http.Client 会导致连接池丢失，短时间高频重试可能触发 dial tcp: too many open files 
新建 sql.DB 不释放旧连接，造成连接泄漏，DB 侧出现 too many connections 
真正要重试的是“请求动作”（如 client.Do(req)），不是“构造 client”这个初始化动作

唯一需要重置的是**有状态的中间对象**，比如自定义的 Token holder、临时缓存 map、或非幂等的 request body（需重新 bytes.NewReader）。