Go语言中，Goroutine的panic需通过defer+recover在各自协程内捕获，否则会导致程序崩溃；recover仅作用于当前Goroutine，因此每个go语句应独立封装recover逻辑，如使用goWithRecover统一处理，确保局部错误不影响整体服务稳定性。
在Go语言中，Goroutine的异常处理是一个关键问题。由于每个Goroutine是独立执行的，一个Goroutine发生panic不会直接影响其他Goroutine或主线程，但若不处理，会导致该协程崩溃并终止程序。通过panic、recover机制，可以在并发场景中优雅地捕获和恢复错误。
理解 Goroutine 中的 Panic 行为
当某个Goroutine中发生panic且未被捕获时，它会打印堆栈信息并终
止该协程。如果主Goroutine退出，整个程序结束；而其他子Goroutine即使仍在运行，也会被强制中断。
例如：
func badGoroutine() {panic("oh no!")
}
go badGoroutine() // 这个panic会导致程序崩溃
如果不加控制，这种行为可能导致服务意外中断。因此，在高并发程序中，必须对每个可能出错的Goroutine做保护性处理。
使用 defer + recover 捕获 Panic
recover只能在defer函数中生效，用于捕获当前Goroutine中的panic，并阻止其继续向上蔓延。
常见做法是在启动Goroutine时包裹一层recover机制：
func safeWorker() {defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered from:", r)
}
}()
// 业务逻辑
panic("something went wrong")
}
go safeWorker() // 不再导致程序退出
这样即使发生panic，也能被拦截，保证程序继续运行。
在并发任务中统一处理 Panic
在实际项目中，比如协程池、任务队列或HTTP中间件中，通常会封装通用的错误恢复逻辑。
可以定义一个通用的goroutine启动器：
func goWithRecover(fn func()) {go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("Panic recovered: %v", r)
}
}()
fn()
}()
}
使用方式：
goWithRecover(func() {doSomethingRisky()
})
这种方式提高了代码安全性与可维护性，避免遗漏recover。
注意 Recover 的作用范围
recover只对当前Goroutine有效，无法跨协程捕获panic。这意味着每个独立的go语句内部都需要有自己的recover机制。
以下写法是无效的：
defer func() {recover() // 无法捕获子Goroutine的panic
}()
go func() {
panic("outside scope")
}()
必须将recover放在子Goroutine内部才能起作用。
基本上就这些。只要在每个可能出问题的Goroutine中正确使用defer+recover，就能有效防止程序因局部错误而整体崩溃。这在构建稳定的服务（如Web服务器、后台任务）时尤为重要。
