go中无法用try/catch捕获panic，必须用defer+recover在goroutine内兜底，且仅对当前goroutine有效；panic会中断当前函数并逐层触发defer，未recover则导致该goroutine崩溃并打印stack trace，主goroutine panic才退出进程。
Go 里无法用 try/catch 捕获运行时 panic，必须靠 recover() 配合 defer 在 goroutine 内部做“兜底”，且仅对当前 goroutine 有效。
panic 会中断当前 goroutine，但不会终止整个程序
Go 的 panic 不是传统异常，它会立即停止当前函数执行链，并逐层向上触发 defer。如果没被 recover() 拦住，最终导致该 goroutine 崩溃并打印 stack trace——主 goroutine panic 才会让进程退出。
- 常见触发场景：
nil指针解引用、切片越界（slice[i]超出长度）、向已关闭 channel 发送数据、空接口断言失败（x.(T)失败且未用, ok形式） -
panic()接收任意值（string、error、甚至struct{}），但recover()只能捕获它返回的原始值，类型需自行断言 - 注意：在非
defer函数中调用recover()总是返回nil，它只在 defer 中且 panic 正在传播时生效
正确使用 recover() 的典型模式
必须把 recover() 放在 defer 函数内部，且该 defer 必须在 panic 触发前注册（即 panic 发生在 defer 注册之后）。
func riskyOp() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
// 这里可做清理、上报、或重新 panic
}
}()
// 可能 panic 的代码，比如：
var s []int
_ = s[0] // panic: index out of range
}
- 不要在顶层函数（如
main()）里无差别 recover —— 它会掩盖真正需要修复的逻辑错误 - 适合 recover 的场景：HTTP handler、长期运行的 worker、插件沙箱等“边界隔离”位置
- 若想继续传播 panic，可在 recover 后调用
panic(r)，但注意这会再次触发 defer 链，可能造成重复日志
recover 无法捕获的“错误”类型
recover() 只对 panic() 有效，对真正的错误（error 值）完全无感——它们本就不该 panic，而应显式返回、检查、处理。
立即学习“go语言免费学习笔记（深入）”；
- IO 错误（
os.Open返回error）、JSON 解析失败（json.Unmarshal返回error）、数据库查询超时等，都属于常规控制流，必须用if err != nil判断 - 混淆 panic 和 error 是 Go 新手最常踩的坑：比如把
http.ListenAndServe的返回 error 直接忽略，结果服务静默退出；或者对本该检查的err却去写 recover - 某些标准库函数（如
template.Execute）会在内部 panic，这时 recover 才有意义——但前提是你知道它会 panic，且你愿意承担“吞掉错误”的后果
调试 panic 的实用技巧
panic 的 stack trace 默认只显示到当前 goroutine，深层调用或协程间传播时容易丢失上下文。
- 用
runtime/debug.PrintStack()在 recover 里补全完整栈，比单纯fmt.Printf("%v", r)信息量大得多 - 启动时加
GODEBUG=panicnil=1环境变量，能让 nil 指针解引用 panic 显示更精确的行号（Go 1.22+ 默认启用） - 在测试中主动触发 panic 并验证 recover 行为：用
testify/assert.Panics或原生testing.T.CaptureOutput检查日志输出 - 生产环境建议用
gopkg.in/airbrake/gobrake.v2类库自动上报 panic，但注意别把敏感字段（如用户 token）打进去
真正难的不是写 recover，而是判断哪里该 panic、哪里该返回 error、哪里该提前校验——Go 把错误处理决策权交给了你，而不是 runtime。
