goroutine 中 panic 无法被外层 defer 捕获，必须在每个 goroutine 内部用 defer recover() 处理；errgroup.Group 可安全统一管理多 goroutine 错误；channel 发送错误需避免关闭后发送或死锁。
goroutine 中 panic 无法被外层 defer 捕获
在 Go 中，每个 goroutine 有独立的调用栈，panic 只会终止当前 goroutine，且不会传播到启动它的 goroutine。这意味着你在主函数里写 defer recover()，对子 goroutine 内部的 panic 完全无效。
常见错误现象：程序没崩溃，但某 goroutine 静默退出，日志没输出，逻辑中断——你根本不知道它挂了。
- 必须在每个可能 panic 的 goroutine 内部做
defer recover() - recover() 只在 defer 函数中有效，且仅能捕获当前 goroutine 的 panic
- recover() 返回
nil表示没有 panic 发生，需显式判断
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panicked: %v", r)
}
}()
// 可能 panic 的代码，比如 map 并发写、空指针解引用等
m := make(map[string]int)
m["key"] = 42
delete(m, "key")
// 注意：这里如果误用未初始化的指针或 channel，就容易 panic
}()使用 errgroup.Group 统一收集 goroutine 错误
当多个 goroutine 执行任务并需要返回错误时，手动用 sync.WaitGroup + chan error 容易出错（如漏 send、死锁、重复 close）。errgroup.Group 是更安全的选择，它自动等待所有 goroutine 结束，并在任意一个返回非 nil error 时取消其余任务（可选）。
注意：errgroup.Group 的 Go 方法接收的是 func() error，不是无参函数；错误由 group 自动聚合，无需额外 channel。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 导入：
"golang.org/x/sync/errgroup" - 默认行为是“首次出错即取消”，可通过
WithContext控制取消逻辑 - 若不希望短路（即全部执行完再汇总错误），需自行管理
errgroup.WithContext(context.Background())并禁用 cancel
g := new(errgroup.Group)
for _, url := range urls {
url := url // 避免循环变量复用
g.Go(func() error {
resp, err := http.Get(url)
if err != nil {
return fmt.Errorf("fetch %s failed: %w", url, err)
}
defer resp.Body.Close()
return nil
})
}
if err := g.Wait(); err != nil {
log.Printf("at least one request failed: %v", err)
}channel 发送错误时的典型 panic 场景
并发中常通过 chan error 收集结果，但若 channel 已关闭或未缓冲且无人接收，send 操作会 panic（send on closed channel 或 deadlock）。这类错误不会触发 recover，除非你把 send 包在 defer-recover 里——但这通常掩盖了设计问题。
正确做法是控制 channel 生命周期：要么用带缓冲 channel 避免阻塞，要么确保发送前 channel 未关闭，或用 select + default 做非阻塞发送。
- 不要在 goroutine 退出后还往同一 channel 发送
- 关闭 channel 应由 sender 负责，receiver 不应 close
- 多个 sender？改用
sync.Once或统一由某个 goroutine 关闭
errCh := make(chan error, len(tasks)) // 缓冲大小匹配任务数
for _, task := range tasks {
go func(t Task) {
err := t.Run()
select {
case errCh <- err:
default: // 避免阻塞，但需确保容量足够
}
}(task)
}
close(errCh)
for err := range errCh {
if err != nil {
log.Println("task error:", err)
}
}context.WithCancel 配合 goroutine 错误传播
当一个 goroutine 出错，你想让其他相关 goroutine 主动退出（比如超时、认证失败、配置加载失败），靠共享变量或 channel 通知容易遗漏。用 context.Context 是 Go 官方推荐方式，尤其配合 context.WithCancel 或 context.WithTimeout。
关键点：所有子 goroutine 必须监听 ctx.Done()，并在收到信号后清理资源、退出；父 goroutine 在发现错误后调用 cancel()。
- 不要在 goroutine 中直接调用
cancel()，除非你明确知道它是 canceler -
ctx.Err()在Done()关闭后才非 nil，需用select监听 - HTTP server、database query、time.Sleep 等标准库函数都接受 context，优先使用它们的 context 版本
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
<p>go func() {
select {
case <-time.After(5 * time.Second):
cancel() // 主动取消
}
}()</p><p>go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
log.Println("worker exiting due to context cancel")
return
default:
// 执行工作
time.Sleep(100 * time.Millisecond)
}
}
}(ctx)实际中最容易被忽略的是：recover 只对当前 goroutine 有效，且必须写在 defer 里；而错误传播真正可靠的方式不是靠 panic/recover，而是靠显式 error 返回 + context 控制生命周期。别试图用 recover 拦截所有并发异常——它只是兜底，不是主干逻辑。
