协程内错误必须显式传递，不可直接返回或panic；应通过channel、回调或结构体字段传出，推荐用带缓冲的error channel统一收集并由主协程处理。

协程内错误不能直接返回，必须显式传递

Go 的 goroutine 是并发执行的独立单元，启动后与主协程无天然返回通道。若协程内部发生 panic 或返回 error，不主动处理就会被静默丢弃，导致错误“消失”。因此，所有关键逻辑都应避免在 goroutine 内部直接 log.Fatal 或 panic，而要将错误通过 channel、回调函数或结构体字段等方式传出。

用 channel 统一收集错误（推荐方式）

定义一个 error 类型的 channel，容量建议设为预期最大错误数（或使用无缓冲 channel 配合 select 防阻塞）。每个 goroutine 在出错时向该 channel 发送 error；主协程持续接收并集中处理：

• 启动前初始化：errCh := make(chan error, 10)
• 协程中：遇到错误时写入 errCh
• 主协程中用 for i := 0; i 收集
• 注意：需确保发送方不会因 channel 满而阻塞，可配合 select { case errCh

用 WaitGroup + 错误切片实现同步等待与聚合

适用于需要等全部 goroutine 结束后再统一判断成败的场景。定义一个带锁的错误收集器：

• 声明 var mu sync.Mutex 和 var errors []error
• 每个 goroutine 结束前： mu.Lock(); errors = append(errors, err); mu.Unlock()
• 主协程调用 wg.Wait() 后检查 len(errors)，或用 errors.Join(errors...)（Go 1.20+）合并
• 适合调试或批处理任务，但要注意并发写 slice 的安全性，不可省略互斥锁

封装成可复用的异步执行器（ErrGroup）

参考 golang.org/x/sync/errgroup 的设计思想，自建轻量版：

• 定义结构体 type AsyncRunner struct { errCh chan error; wg sync.WaitGroup }
• 提供 Go(f func() error) 方法：自动 wg.Add(1)，启动 goroutine 并捕获 error 后发往 errCh
• 提供 Wait() []error：关闭 channel，收集所有错误，返回非 nil 错误列表
• 优势是调用简洁、错误语义明确，且天然支持上下文取消（可扩展 ctx 参数）

协程错误管理的核心不是“捕获”，而是“显式导出”。只要确保每条错误路径都有出口，并由单一责任点汇总，就能避免错误遗漏和调试困难。