协程中 panic 无法被外层 defer 捕获，必须在每个 goroutine 内部用 defer/recover 处理；推荐通过 channel 传递 error、用 context 控制超时与取消、用 errgroup 统一管理错误。
协程中 panic 无法被外层 defer 捕获
Go 的 goroutine 是独立的执行流，其内部发生的 panic 不会传播到启动它的主协程或其他协程。这意味着你在主函数里用 defer/recover 完全捕获不到子协程里的崩溃。
- 典型现象：
panic: runtime error: index out of range直接终止整个程序，哪怕外层有recover() - 根本原因：每个
goroutine有自己的调用栈和 panic 栈，recover()只对当前 goroutine 有效 - 正确做法：必须在每个可能出错的协程内部做
defer/recover
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panic: %v", r)
}
}()
// 可能 panic 的逻辑，比如 slice 越界、nil 指针解引用
_ = []int{1}[5]
}()使用 channel 配合 error 类型传递错误结果
当协程需要返回计算结果或错误时，推荐用 chan error 或带 error 字段的结构体通道（如 chan Result），避免靠日志“猜”哪里失败了。
- 适用场景：多个协程并行请求 API、批量处理文件、数据库批量插入
- 注意点：channel 必须有缓冲或确保接收方已就绪，否则协程可能阻塞甚至泄露
- 不要用全局变量或共享 map 存错误 —— 竞态风险高，且难以追踪来源
type Result struct {
Data string
Err error
}
ch := make(chan Result, 10) // 缓冲足够容纳所有结果
go func() {
defer close(ch)
for _, url := range urls {
resp, err := http.Get(url)
ch <- Result{Data: url, Err: err}
}
}()
for r := range ch {
if r.Err != nil {
log.Printf("failed on %s: %v", r.Data, r.Err)
}
}
context.WithCancel + select 处理超时与主动取消时的错误清理
协程不是孤立存在的，常需响应上下文取消（如 HTTP 请求超时、用户中断）。若只依赖 channel 接收，可能错过取消信号，导致资源泄漏或重复错误。
-
select中必须包含分支，并检查ctx.Err()判断是超时还是主动取消 - 在
ctx.Done()分支里做清理（关闭文件、释放锁、通知下游），而不是直接 return - 别在协程里反复调用
ctx.Err()—— 应该用select等待它，否则浪费 CPU
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel()go func(ctx context.Context) { defer func() { if r := recover(); r != nil { log.Printf("panic in worker: %v", r) } }() select { case <-time.After(5 * time.Second): log.Println("work done") case <-ctx.Done(): log.Printf("canceled: %v", ctx.Err()) // 输出 context deadline exceeded 或 canceled // 这里可以关闭连接、释放内存等 } }(ctx)
error group（errgroup）统一等待与错误聚合
标准库没有内置 error group，但 golang.org/x/sync/errgroup 是事实标准。它解决的是「等所有协程结束，只要一个出错就提前返回」的问题，比手写 sync.WaitGroup + 全局 error 变量更安全、更清晰。
- 默认行为：第一个非
nil错误触发Wait()返回，其余协程仍运行（除非你传入ctx控制生命周期） - 若要“任意错误即停止所有”，必须配合
context.WithCancel，并在每个协程中监听ctx.Done() - 注意：
eg.Go()启动的函数签名必须是func() error，不能直接传带参数的闭包（需显式捕获）
g, ctx := errgroup.WithContext(ctx)
for _, task := range tasks {
task := task // 避免循环变量复用
g.Go(func() error {
select {
case <-ctx.Done():
return ctx.Err()
default:
return doWork(task)
}
})
}
if err := g.Wait(); err != nil {
log.Printf("at least one task failed: %v", err)
}实际项目里最易忽略的是 panic 恢复的粒度 —— 很多人只在顶层加 recover，却忘了每个新起的 goroutine 都是新的 panic
