goroutine 中无法用 return 返回错误，因 return 仅作用于当前协程；必须通过通道、回调或加锁共享变量显式传递错误，推荐使用带缓冲的 chan error 并确保发送（含 nil）。
goroutine 中无法直接用 return 返回错误
Go 的 goroutine 是独立执行的，return 只作用于当前协程函数，主 goroutine 拿不到子 goroutine 的返回值或错误。常见错误是写成这样：
go func() {
if err := doSomething(); err != nil {
return // 这里 return 完全没用，主流程根本收不到
}
}()必须显式把错误“送出去”。常用方式有三种：通道、回调函数、共享变量（需加锁）。通道最符合 Go 的并发哲学，推荐优先使用。
用 chan error 收集 goroutine 错误最稳妥
为每个 goroutine 分配一个 error 类型通道，或复用一个带缓冲的通道，避免阻塞。注意别漏掉发送——哪怕成功也要发 nil，否则主 goroutine 可能永远卡在 recv 上。
- 用无缓冲通道时，务必确保接收方已就绪，否则 goroutine 会阻塞退出
- 用带缓冲通道（如
make(chan error, 10)）更安全，但缓冲大小要大于可能并发数 - 多个 goroutine 写同一个通道时，无需额外同步；但若混用
close()和循环接收，需协调好关闭时机，否则可能 panic
示例片段：
立即学习“go语言免费学习笔记（深入）”；
errCh := make(chan error, 2)
go func() { errCh <- doTask1() }()
go func() { errCh <- doTask2() }()
for i := 0; i < 2; i++ {
if err := <-errCh; err != nil {
log.Println("task failed:", err)
}
}
sync.WaitGroup + 共享 error 变量需加锁
如果不想引入通道，可以用 sync.WaitGroup 控制等待，并用 sync.Once 或 sync.Mutex 保护首个错误写入。因为多数场景只关心“有没有错”，而非所有错误。
- 用
sync.Once配合指针变量，保证只记录第一个非 nil 错误 - 用
sync.Mutex可以收集全部错误（比如存进切片），但要注意切片不是线程安全的 - 切忌直接写全局变量或闭包变量而不加锁——竞态检测器（
go run -race）大概率报错
典型模式：
var mu sync.Mutex var firstErr error var wg sync.WaitGroupwg.Add(2) go func() { defer wg.Done() if err := doTask1(); err != nil { mu.Lock() if firstErr == nil { firstErr = err } mu.Unlock() } }()
context.WithTimeout 配合错误传递可自动中断长期 goroutine
当某个 goroutine 可能卡住（比如网络请求、文件读取），仅靠通道或 WaitGroup 无法及时止损。此时应把 context.Context 传入子任务，并在出错或超时时统一返回错误。
-
context.WithTimeout创建的 ctx 超时后，ctx.Err()会返回context.DeadlineExceeded，可直接作为错误处理 - 所有 I/O 函数（如
http.Client.Do、os.Open）都支持传入ctx，务必利用起来 - 不要自己手动检查
ctx.Err() == nil后再继续——应该用select配合ctx.Done()实现响应式退出
关键结构：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()go func(ctx context.Context) { select { case <-time.After(10 * time.Second): // 模拟慢操作 case <-ctx.Done(): return // 被取消，不继续 } }(ctx)
实际项目里，错误传递方式往往组合使用：用 context 控制生命周期，用 chan error 汇总结果，用 sync.Once 做兜底记录。最容易被忽略的是通道缓冲大小和关闭时机——这两个点一旦出错，程序不会立刻 panic，但会在高并发下随机丢错误或死锁。
