panic仅终止当前goroutine，recover必须在defer中调用才能捕获同一goroutine的panic；常规错误应返回error而非滥用panic/recover。
panic 会直接终止当前 goroutine，不是 try-catch
Go 没有传统异常机制，panic 是运行时崩溃信号，触发后默认打印栈、退出程序。它不被“捕获”就结束，更不是控制流工具。
常见错误现象：panic: runtime error: index out of range 这类错误一旦没被 recover 拦住，整个 goroutine 就挂了，主 goroutine 挂则进程退出。
-
panic只影响当前 goroutine，其他 goroutine 不受影响（除非它们也 panic 或依赖已死的资源） - 不能在任意位置调用
recover：必须在defer函数中，且该函数必须由当前 panic 的 goroutine 执行 - 如果在普通函数里写
recover()，返回值永远是nil—— 它根本不起作用
recover 必须和 defer 配合，且只能在 panic 发生的同一 goroutine 中生效
recover 不是全局钩子，它像一个“急救包”，只对当前 goroutine 最近一次未处理的 panic 有效，而且必须靠 defer 提前注册好。
使用场景：HTTP handler 中防止某个请求 panic 导致整个服务崩掉；解析第三方数据时兜底容错。
立即学习“go语言免费学习笔记（深入）”；
- 写法必须是：
defer func() { if r := recover(); r != nil { /* 处理 */ } }() - 不能写成
defer recover()—— 这只是立即执行recover，此时还没 panic，返回nil - 不能把
recover放到另一个函数里再 defer，比如defer handlePanic()，除非handlePanic内部自己做了func() { recover() }()
func risky() {
defer func() {
if err := recover(); err != nil {
log.Printf("caught panic: %v", err)
}
}()
panic("something went wrong")
}不要用 panic/recover 做常规错误处理
Go 的惯用法是返回 error 值，panic 应该留给真正“不该发生”的事，比如程序逻辑断言失败、不可恢复的初始化错误。
性能影响：panic 触发时要构建完整栈信息，开销远大于 return error；频繁 panic 会拖慢程序，也掩盖真实问题。
- HTTP handler 里对用户输入 panic 是危险的 —— 应该 validate + return
http.Error - 数据库查询失败、文件不存在、网络超时，这些都该走
if err != nil分支，不是 panic - 测试中用
panic模拟故障可以，但生产代码里用它替代错误判断，等于把 bug 包装成“异常”
recover 捕获不到所有 panic 场景，比如 runtime 系统级崩溃
recover 能拦住你主动 panic("msg") 或空指针解引用这类语言级 panic，但拦不住某些底层崩溃，比如 Cgo 崩溃、栈溢出、内存耗尽、调用 os.Exit 后的强制退出。
兼容性影响：不同 Go 版本对某些 panic 的触发时机或内容有微调（如 map 并发读写在 1.20+ 报错更早），别依赖 panic 文案做逻辑分支。
- 并发写 map 触发的
fatal error: concurrent map writes可以被 recover 拦住，但程序状态已损坏，继续运行风险高 -
runtime.GC()或debug.SetGCPercent(-1)不会导致 panic，但误用可能引发 OOM，这种 recover 不了 - 跨 goroutine 的 panic 无法传递 —— 想让 worker panic 影响主流程，得靠 channel 或 context.Done()
事情说清了就结束。关键点就两个：panic 是 goroutine 级别的硬中断，recover 是它唯一的软着陆方式，但只在 defer 里有效；其余时候，老老实实写 if err != nil。
