goroutine 中 panic 无法被外部 defer 捕获，必须在内部用 defer+recover 处理；errgroup.group 可聚合显式 error 但不捕获 panic；向 channel 发送时 panic 会导致死锁，需先 recover 再 send 或用超时机制。
goroutine 中 panic 无法被外部 defer 捕获
Go 的 goroutine 是独立的执行流，内部发生的 panic 不会传播到启动它的 goroutine，外部的 defer + recover 完全无效。这是并发错误处理最常踩的坑——你以为加了 recover 就安全了，其实 panic 已经让那个 goroutine 静默退出。
正确做法是在每个可能出错的 goroutine 内部做错误兜底：
- 必须在
goroutine函数体第一行就写defer func() { if r := recover(); r != nil { /* 记录日志或通知 */ } }() - 不要依赖父 goroutine 的
recover，它对子 goroutine 的崩溃无感知 - 如果 goroutine 承担关键任务（如消息消费、定时任务），recover 后建议主动退出或重试，避免状态不一致
使用 errgroup.Group 统一收集 goroutine 错误
errgroup.Group 是标准库 golang.org/x/sync/errgroup 提供的工具，能自然地把多个 goroutine 的错误聚合起来，比手写 channel + select 更简洁可靠。
典型用法：
立即学习“go语言免费学习笔记（深入）”；
g, _ := errgroup.WithContext(ctx)
for _, task := range tasks {
task := task // 防止循环变量复用
g.Go(func() error {
return doSomething(task)
})
}
if err := g.Wait(); err != nil {
// 至少一个 goroutine 返回了非 nil error
log.Println("some task failed:", err)
}
-
errgroup.Group在第一个 error 返回时就会取消其余 goroutine（需传入带 cancel 的ctx） - 它只捕获显式返回的
error，对panic依然无能为力，所以仍需在Go函数内加recover - 若需区分哪个 task 出错，建议在 error 中带上标识，比如
fmt.Errorf("task %s failed: %w", task.ID, err)
channel 发送 panic 导致的死锁
当 goroutine 在向 unbuffered channel 或已满的 buffered channel 发送数据时 panic，且没有被 recover，该 goroutine 会直接终止，但 channel 发送操作尚未完成——这会导致接收方永远阻塞，引发死锁（runtime error: all goroutines are asleep）。
- 避免在可能 panic 的路径上直接向 channel 发送：先判断、先 recover、再 send
- 使用带超时的发送：
select { case ch - 更稳妥的方式是把结果和 error 封装进结构体，统一通过 channel 传递，由接收方检查 error 字段
context.WithCancel 被意外关闭导致“假失败”
很多人用 errgroup.WithContext 或手动管理 context 时，会在任意 goroutine 出错后调用 cancel()，但没注意：cancel 本身不区分错误类型——网络超时、业务校验失败、甚至日志写入失败都会触发全局退出。
- 不是所有 error 都该 cancel 整个 group；例如某个 task 因临时限流失败，其他 task 仍可继续
- 可自定义错误分类：
if errors.Is(err, ErrTransient) { continue }，仅对ErrCritical调用 cancel - 务必确保 cancel 函数只被调用一次，重复调用虽不 panic，但会让后续 context.Done() 立即返回，干扰正常流程
并发错误处理真正的难点不在语法，而在于区分哪些错误该隔离、哪些该传播、哪些该忽略——这些决策藏在业务语义里，代码只是执行者。
