goroutine 错误无法自动传播到主 goroutine，需通过 channel+WaitGroup 或 errgroup.Group 显式传递；recover 不跨协程生效，panic 不能替代 error 返回；错误处理核心在于明确失败策略而非仅技术选型。
goroutine 中的错误无法自动传播到主 goroutine
Go 的 goroutine 是独立执行的，一旦启动就和发起它的函数解耦。这意味着在子 goroutine 里调用 return 或发生 panic，不会中断主流程，更不会把错误“带回来”。常见表现是：主程序早早退出，而子任务里的 fmt.Println("failed:", err) 根本没来得及打印。
- 别指望用普通变量（如
err error）跨 goroutine 赋值 —— 竞态风险高，且无法同步完成状态 - 不要在 goroutine 内部直接
log.Fatal或os.Exit，这会杀掉整个进程，不是错误处理而是粗暴终止 - 如果多个 goroutine 都可能出错，需明确“只要一个错就失败”还是“等全部完成再汇总”
用 sync.WaitGroup + chan error 收集所有错误
这是最常用、最可控的方式：主 goroutine 启动工作协程，每个协程把错误发到同一个 chan error，主 goroutine 用 WaitGroup 等待全部结束，再统一读取错误通道。注意通道必须带缓冲，或配合 close 使用，否则可能阻塞。
var wg sync.WaitGroup errCh := make(chan error, 5) // 缓冲大小 ≥ 可能出错的 goroutine 数量for i := 0; i < 5; i++ { wg.Add(1) go func(id int) { defer wg.Done() if id == 2 { errCh <- fmt.Errorf("task %d failed", id) return } // 模拟成功任务 time.Sleep(10 * time.Millisecond) }(i) }
go func() { wg.Wait() close(errCh) // 所有 goroutine 完成后关闭通道 }()
var errors []error for err := range errCh { errors = append(errors, err) }
if len(errors) > 0 { fmt.Printf("got %d errors: %v\n", len(errors), errors) }
用 errgroup.Group 简化错误传播逻辑
golang.org/x/sync/errgroup 封装了上述模式，自动处理首次错误取消、等待、通道管理。它适合“任一错误即整体失败”的场景（如并行初始化多个服务），也支持忽略部分错误继续执行。
- 调用
eg.Go启动任务，返回的第一个非 nilerror会立刻被eg.Wait()返回 - 若想收集全部错误，需自己维护切片并在每个
eg.Go回调中追加，errgroup不提供内置聚合 - 注意
WithContext版本可配合超时或取消控制，避免某个 goroutine 卡死拖垮全局
import "golang.org/x/sync/errgroup"ctx := context.Background() eg, ctx := errgroup.WithContext(ctx)
for i := 0; i < 3; i++ { i := i // 避免闭包引用同一变量 eg.Go(func() error { if i == 1 { return fmt.Errorf("failed on index %d", i) } time.Sleep(10 * time.Millisecond) return nil }) }
if err := eg.Wait(); err != nil { fmt.Println("first error:", err) // 输出 failed on index 1 }
panic 和 recover 不适用于跨 goroutine 错误传递
recover 只能在同一线程（即同一个 goroutine）内捕获本 goroutine 的 panic。从 A goroutine panic，B goroutine 调用 recover 是无效的 —— 它什么也捞不到，还会触发 runtime panic。
立即学习“go语言免费学习笔记（深入）”；
- 在 goroutine 内部做
defer/recover只是为了防止崩溃，不能替代错误返回机制 - 把 recover 到的 panic 转成 error 再通过 channel 发出去，是可行的折中方案，但属于“兜底”，不该是主错误路径
- 滥用 recover 会让错误堆栈丢失原始位置，调试困难；优先用显式 error 返回
真正难的不是选哪种方式，而是提前想清楚：这个并发操作失败后，程序该继续运行、重试、降级，还是立即停止？错误收集只是手段，决策逻辑才是关键。
