协程中的panic需特别处理，因其不会自动传播至主协程，但会导致整个程序退出。例如子协程中未捕获的panic虽不阻塞主流程，仍会终止进程。通过defer+recover可捕获协程内panic，防止扩散。标准做法是在goroutine中使用defer声明recover函数，捕获并处理异常值。为减少重复代码，可封装safeGo等通用保护函数，自动为协程添加recover机制。注意recover必须在defer中调用，且仅对当前协程有效，无法跨协程捕获。recover返回panic传递的值，建议进行类型判断以合理处理不同类型的panic。生产环境中应在每个可能出错的协程中设置recover，确保程序健壮性。
在Go语言中，协程（goroutine）是实现并发的核心机制。但当一个协程中发生panic时，它不会像主线程那样被主程序直接感知，如果不加以处理，可能导致程序崩溃或难以排查的问题。因此，正确捕获并处理协程中的panic至关重要。
为什么协程中的panic需要特别处理
Go的主goroutine如果发生panic且未被捕获，程序会直接终止。而其他子goroutine中发生的panic只会导致该协程崩溃，并不会自动传播到主协程。这意味着即使你的主流程正常运行，某个后台协程因panic退出也可能造成数据丢失、资源泄漏等问题。
例如：
func main() {go func() {
panic("协程内 panic")
}()
time.Sleep(2 * time.Second)
fmt.Println("主程序继续运行...")
}
这段代码会输出panic信息，然后程序退出，尽管主函数还在sleep。这说明子协程的panic虽不阻塞主协程执行流，但仍会导致整个进程退出。
立即学习“go语言免费学习笔记（深入）”；
使用defer + recover捕获协程中的panic
在协程内部通过defer结合recover()可以捕获panic，防止其扩散。
标准做法是在协程启动时立即设置recover机制：
go func() {defer func() {
if r := recover(); r != nil {
fmt.Printf("捕获到panic: %v\n", r)
}
}()
// 可能出错的业务逻辑
var m map[string]int
m["key"] = 1 // 触发panic: assignment to entry in nil map
}()
这样即使发生panic，也会被当前协程的defer recover捕获，程序将继续运行。
封装通用的panic保护函数
为了减少重复代码，可以封装一个安全执行协程的辅助函数：
func safeGo(f func()) {go func() {
defer func() {
if r := recover(); r != nil {
fmt.Printf("safeGo 捕获panic: %v\n", r)
// 可选：打印堆栈
log.Printf("Stack trace: %s", debug.Stack())
}
}()
f()
}()
}
使用方式：
safeGo(func() {panic("测试panic")
})
这种方式提升了代码的健壮性和可维护性，尤其适合在大量goroutine场景下使用。
recover的注意事项
recover必须配合defer使用：只有在defer声明的函数中调用recover才有效。直接在函数体中调用recover将始终返回nil。
recover只能捕获同一goroutine的panic：不能跨协程捕获，每个协程需独立设置recover机制。
panic可以传递值：recover返回的是panic传入的值，可能是字符串、error或其他类型，建议做类型判断：
if r := recover(); r != nil {switch v := r.(type) {
case string:
fmt.Println("panic string:", v)
case error:
fmt.Println("panic error:", v)
default:
fmt.Println("未知panic类型")
}
}
基本上就这些。只要在每个可能出错的协程中合理使用defer+recover，就能有效防止panic导致程序意外退出。虽然Go鼓励用error代替异常流程，但在某些边界情况或第三方库调用中，panic仍可能发生，做好防护是生产级代码的基本要求。
