panic会中断当前goroutine执行并展开调用栈执行defer，若无recover则程序崩溃；常见场景有nil指针解引用、切片越界、向已关闭channel发送数据。
panic 会中断当前 goroutine 的执行流程
Go 没有传统意义的“异常”，panic 是一种运行时错误信号，一旦触发，当前 goroutine 会立即停止执行后续语句，并开始向上展开调用栈，依次执行所有已注册的 defer 函数。如果没有任何 recover 拦截，程序最终会崩溃并打印堆栈。
常见触发 panic 的场景包括：
-
nil指针解引用（如var p *int; fmt.Println(*p)） - 切片越界访问（如
s := []int{1}; s[5]） - 向已关闭的 channel 发送数据（
close(ch); ch ） - 显式调用
panic("msg")
recover 必须在 defer 中调用才有效
recover 不是全局捕获器，它只在 defer 函数中调用时才有意义，且仅能捕获**当前 goroutine** 中由 panic 引发的中断。如果写成普通函数调用（不在 defer 里），recover 总是返回 nil，起不到任何作用。
正确写法示例：
立即学习“go语言免费学习笔记（深入）”；
func safeDivide(a, b int) (result int, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panic occurred: %v", r)
}
}()
if b == 0 {
panic("division by zero")
}
result = a / b
return
}关键点：
-
recover()必须出现在defer内部的匿名函数或命名函数中 - 不能跨 goroutine 恢复：在一个 goroutine 中
panic，另一个 goroutine 中的recover无效 - 恢复后，原函数不会“继续执行”，而是直接返回——因为
panic已经让控制流跳出到最近的defer
recover 返回值类型是 interface{}，需类型断言处理
recover() 返回的是 interface{}，实际值取决于 panic 传入的内容。如果是字符串，就用 string(r)；如果是自定义错误，建议统一用 error 类型 panic，便于断言：
panic(fmt.Errorf("invalid input: %s", input))
<p>// recover 后可安全断言为 error
if r := recover(); r != nil {
if err, ok := r.(error); ok {
log.Printf("caught error: %v", err)
} else {
log.Printf("caught non-error panic: %v", r)
}
}不推荐直接 panic("xxx") 后又想当成 error 处理，因为字符串和 error 是不同底层类型，断言会失败。
其他注意事项：
- 多次调用
recover()只有第一次有效，后续都返回nil - 不要滥用
recover替代正常错误处理，比如本该用if err != nil判断的地方，不应靠panic/recover拦截 - HTTP handler 中常用于兜底防止整个服务因单个请求 panic 而退出，但日志必须记录原始 panic 堆栈（
debug.PrintStack()）
goroutine 泄漏与 recover 的边界问题
在启动新 goroutine 的场景下，recover 容易被误认为能“保护主线程”。其实不然：每个 goroutine 独立拥有自己的 panic/recover 生态。主线程中写的 defer + recover 对子 goroutine 中的 panic 完全无感。
例如以下代码无法捕获子 goroutine 的 panic：
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("this will NOT catch the goroutine panic")
}
}()
go func() {
panic("inside goroutine")
}()
time.Sleep(100 * time.Millisecond)
}真正有效的做法是在子 goroutine 内部加 defer/recover：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine recovered: %v", r)
}
}()
panic("inside goroutine")
}()最容易被忽略的一点：recover 后未做任何处理（比如没记录日志、没返回错误、没通知监控），等于把 panic “静默吞掉”，会让问题更难定位。线上环境务必确保 recover 后至少有明确日志输出。
