goroutine 中不能直接 return error，因主协程不等待其结束；正确做法是通过 channel、共享变量或回调传递错误，推荐带缓冲的 channel 配合 sync.WaitGroup 和 context 控制超时与取消。
goroutine 中不能直接 return error
Go 的协程是独立执行的，go func() { ... }() 启动后立即返回，主 goroutine 不会等待它结束，更不会接收它内部的 return err。常见错误是写成这样：
go func() {
if err := doSomething(); err != nil {
return err // 编译失败：无法从无返回值函数中 return error
}
}()这类写法直接报错。真正可行的是把 error 传出去——通过 channel、共享变量（需加锁）、或回调函数。
用 channel 收集 goroutine 错误最常用
定义一个 chan error，每个 goroutine 执行完把 error 发进去；主 goroutine 用 for range 或带超时的 select 接收。注意：必须关闭 channel，否则 range 会永久阻塞。
- 多个 goroutine 共用一个
chan error，容量建议设为并发数（避免阻塞） - 即使某 goroutine 成功，也应发
nil（或跳过发送），方便统一处理 - 若使用
range，务必在所有 goroutine 结束后close(ch)；推荐用sync.WaitGroup配合
errCh := make(chan error, 5)
var wg sync.WaitGroup
<p>for i := 0; i < 5; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
if err := processItem(id); err != nil {
errCh <- err
return
}
errCh <- nil // 显式发送 nil，便于统计
}(i)
}</p><p>go func() {
wg.Wait()
close(errCh)
}()</p><p>var errors []error
for err := range errCh {
if err != nil {
errors = append(errors, err)
}
}context.WithTimeout 配合 cancel 可主动中断错误传播
当某个 goroutine 卡住或耗时过长，仅靠 channel 等不到它的 error。这时要用 context.Context 控制生命周期，并让被调函数支持取消。
立即学习“go语言免费学习笔记（深入）”；
-
context.WithTimeout返回的ctx和cancel必须传入 goroutine - 被调函数（如
http.Do、time.Sleep、自定义函数）需检查ctx.Err()并提前退出 - 不要忽略
ctx.Err()—— 它可能等于context.DeadlineExceeded或context.Canceled，这本身就是一种 error
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
<p>errCh := make(chan error, 1)
go func() {
errCh <- doWithCtx(ctx) // 内部需 select { case <-ctx.Done(): return ctx.Err() }
}()</p><p>select {
case err := <-errCh:
if err != nil && errors.Is(err, context.DeadlineExceeded) {
log.Println("operation timed out")
}
case <-time.After(3 * time.Second):
log.Println("channel hang, but shouldn't happen if cancel works")
}recover 不该用于常规错误处理
有人试图在 goroutine 里用 defer + recover 捕获 panic 并转成 error 发到 channel。这只能兜底程序崩溃，**不能替代正常 error 返回**。
- panic 是异常场景（如空指针解引用、切片越界），不是业务错误（如“用户不存在”、“网络超时”）
- recover 无法捕获其他 goroutine 的 panic；每个 goroutine 需单独 defer
- 滥用 recover 会让错误路径模糊，掩盖真实问题
真正该做的是：确保业务逻辑用 if err != nil 显式判断，只在第三方库可能 panic 且你无法修改源码时，才在 goroutine 内加一层 recover 做防御。
实际并发错误处理的复杂点不在语法，而在责任边界是否清晰：谁负责发起、谁负责超时、谁负责重试、谁汇总错误、错误是否可重入。这些决策比选 channel 还是 WaitGroup 影响更大。
