goroutine 中的 panic 不会传播到主 goroutine，仅终止当前 goroutine；必须在同 goroutine 中用 defer+recover 捕获，且 recover 仅在 defer 中有效；errgroup 需手动 recover 并转为 error；panic 后状态可能不一致，recover 仅为止损非回滚。
goroutine 中的 panic 不会传播到主 goroutine
Go 的并发模型决定了每个 goroutine 是独立的执行单元，panic 发生在子 goroutine 中时，**默认不会中断 main goroutine 或其他 goroutine**，而是直接终止该 goroutine，并打印堆栈（如果未捕获）。这常被误认为“异常消失了”，其实是被静默吞掉了。
- 没有
recover的 goroutine panic 会导致该 goroutine 退出，但程序继续运行 —— 容易掩盖逻辑错误或资源泄漏 - 主 goroutine 的 panic 仍会终止整个程序，行为与其他语言一致
- 标准库如
http.Serve内部已对每个 handler goroutine 做了recover，所以 HTTP 服务不会因单个请求 panic 而崩溃
如何在 goroutine 中安全 recover panic
必须在 panic 发生的同一 goroutine 中调用 recover 才有效。常见写法是用 defer + recover 包裹业务逻辑，且需确保 defer 在 panic 前已注册。
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panicked: %v", r)
// 可选：上报、清理、重试等
}
}()
// 可能 panic 的代码，例如：
// json.Unmarshal(nil, &v)
// slice[100] 索引越界
}()
-
recover()只在 defer 函数中调用才有效；在普通函数里调用始终返回nil - 不要在 defer 里直接
log.Fatal或os.Exit，否则会强制退出整个进程 - recover 后无法“继续执行” panic 发生点之后的代码，只能做清理或降级处理
使用 errgroup.Group 管理多个 goroutine 并统一处理 panic
errgroup.Group 本身不捕获 panic，但它提供了一种结构化方式启动 goroutine，并配合手动 recover 实现错误聚合。适合需要等待全部完成或任意失败即中止的场景。
g, ctx := errgroup.WithContext(context.Background())
for i := range tasks {
i := i // 避免循环变量捕获问题
g.Go(func() error {
defer func() {
if r := recover(); r != nil {
// 将 panic 转为 error，供 errgroup 返回
g.Go(func() error {
return fmt.Errorf("panic in task %d: %v", i, r)
})
}
}()
return doTask(ctx, i)
})
}
if err := g.Wait(); err != nil {
log.Printf("task group failed: %v", err)
}
- 不能直接在
g.Go传入的函数里 recover 后返回 error —— 因为 recover 捕获的是 panic，不是 error - 上面示例中，用额外的
g.Go把 panic 转为 error 是一种可行模式，但要注意避免嵌套 goroutine 泄漏 - 更稳妥的做法是：所有任务函数内部自行 recover 并返回明确 error，让
errgroup原生处理
日志与监控中容易忽略的 panic 来源
很多 panic 来自第三方库或隐式调用，比如 template.Execute、json.Marshal、reflect.Value.Interface()，它们在特定输入下 panic，但调用方未必意识到要包一层 recover。
- HTTP handler、RPC 方法、定时任务这类长期运行的入口点，建议统一加 recover 模板
- 测试时用
runtime.GOMAXPROCS(1)和go test -race能暴露部分并发 panic 场景，但无法替代运行时 recover - 生产环境应结合
debug.SetPanicOnFault(true)（仅 Linux）辅助定位内存类 panic，但注意它会让某些非法指针访问直接 crash，慎用
真正难处理的不是 panic 本身，而是 panic 发生后状态是否一致 —— 比如 channel 已 send 但未 close，mutex 已 Lock 但没 Unlock。recover 只是止损，不是回滚。
