在Go并发编程中，panic会终止当前goroutine，未recover将导致程序崩溃。1. 每个goroutine需独立使用defer+recover捕获panic；2. 主goroutine退出后其他任务行为不可控；3. 可封装GoSafe函数复用恢复逻辑；4. recover仅在defer中有效且不能跨goroutine传递；5. 仅应用于严重异常场景，不替代错误处理。正确使用可隔离错误并保障服务稳定性。
在Go语言的并发程序中，panic会中断当前goroutine的执行流程，若未妥善处理，可能导致整个程序崩溃。由于每个goroutine是独立执行的，一个goroutine中的panic不会自动被其他goroutine捕获，因此必须在每个可能出错的并发任务中显式进行recover，才能实现有效的错误恢复。
为什么并发中的panic需要特别关注
当一个goroutine发生panic且未recover时，该goroutine会直接终止。如果主goroutine（main goroutine）提前退出，而其他goroutine仍在运行，程序行为将不可预测。更严重的是，未被捕获的panic会打印堆栈信息并导致进程退出，影响服务稳定性。
常见场景包括：
- 第三方库调用引发意外panic
- 空指针解引用、数组越界等运行时错误
- defer函数中执行了会引起panic的操作
使用defer和recover进行panic恢复
在每个独立的goroutine中，应通过defer函数调用recover来拦截panic，防止其向上蔓延。
立即学习“go语言免费学习笔记（深入）”；
示例代码：func safeWorker() {
defer func() {
if r := recover(); r != nil {
log.Printf("recovered from panic: %v", r)
}
}()
// 模拟可能panic的操作
panic("something went wrong")
}
启动该worker时：
go safeWorker()
这样即使发生panic，也会被本地defer捕获，不会影响其他goroutine或主程序流程。
封装通用的panic恢复机制
为避免重复编写recover逻辑，可封装一个通用的执行器，用于安全地启动任何函数。
func GoSafe(fn func()) {
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine recovered: %v\n", r)
// 可选：记录堆栈
buf := make([]byte, 2048)
runtime.Stack(buf, false)
log.Printf("stack trace: %s", buf)
}
}()
fn()
}()
}
使用方式：
GoSafe(func() {
panic("test panic")
})
这种方式提升了代码复用性，也增强了程序健壮性。
recover的局限与注意事项
recover只能在defer函数中有效调用。若在普通函数流程中使用，将无法捕获panic。
关键点：
- recover必须配合defer使用
- 它仅能捕获同一goroutine内的panic
- 无法跨goroutine传递或恢复
- recover后程序从panic点之后继续执行，但原调用栈已被展开
不要依赖recover处理常规错误，它应仅用于程序无法预料的异常场景，如接口调用、反射操作等高风险环节。
基本上就这些。只要在每个独立的并发任务中设置好defer+recover，并做好日志记录，就能有效隔离panic的影响，保障服务持续运行。
