Go 语言中 panic 仅用于不可恢复的异常（如空指针、切片越界），recover 必须在 defer 中调用且仅对同 goroutine 有效，实际项目中应避免滥用，仅限 HTTP handler 或长期 goroutine 入口做兜底。
Go 语言没有传统意义上的 try-catch，panic 和 recover 不是为常规错误处理设计的，而是用于应对真正异常、不可恢复的状态（比如空指针解引用、切片越界、栈溢出等），或在必须提前终止 goroutine 执行流时做最后兜底。
什么时候该用 panic？
仅当程序遇到「本不该发生、且无法继续执行」的情况时才调用 panic。例如：
- 函数接收了明显非法的参数（如
time.AfterFunc(-1 * time.Second, f)）且调用方明显违反契约 - 初始化阶段依赖的配置缺失或格式严重错误（如数据库连接串为空字符串）
- 第三方库返回了 nil 指针且你确定它绝不该为 nil（配合断言后 panic）
⚠️ 切勿用 panic 处理可预期的业务错误（如用户密码错误、文件不存在、HTTP 404）。这类情况应返回 error 值并由上层判断。
为什么 recover 必须在 defer 中调用？
recover 只有在 defer 函数执行期间才有效；如果写在普通代码路径里，它永远返回 nil。这是因为 panic 的传播会立即中断当前函数执行，只有 defer 队列会在函数退出前按逆序运行。
立即学习“go语言免费学习笔记（深入）”；
常见错误写法：
func bad() {
if err := doSomething(); err != nil {
recover() // ❌ 永远无效
panic(err)
}
}正确写法（仅在需要拦截 panic 的 goroutine 内部使用）：
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
func good() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
}
}()
doSomethingThatMightPanic()
}
recover 能捕获所有 panic 吗？
不能。关键限制有三个：
-
recover只对**同一 goroutine 内**发生的 panic 有效；跨 goroutine 的 panic 无法被另一个 goroutine 的recover捕获 - 如果 panic 发生在
init函数中，且未被该包内defer+recover拦截，则程序直接终止，无任何 recover 机会 - 运行时致命错误（如
runtime.throw触发的 “invalid memory address”）可能绕过 recover，尤其在 GC 或调度器关键路径中
因此，不要指望 recover 能兜住一切 —— 它只是最后一道脆弱防线，不是错误处理主力。
实际项目中怎么组织 panic/recover？
绝大多数 Go 服务根本不需要显式 recover。真要用，只建议放在以下两个位置：
- HTTP handler 最外层：防止某个 handler panic 导致整个 server crash（但应记录日志并返回 500，而非静默吞掉）
-
长期运行的 goroutine 入口（如
go func() { ... }()）：避免单个 goroutine panic 连带杀死主流程
示例（HTTP handler 封装）：
func withRecover(h http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
log.Printf("[PANIC] %s %s: %v", r.Method, r.URL.Path, r)
}
}()
h(w, r)
}
}注意：recover 后不能“继续执行原逻辑”，只能做清理和响应，因为 panic 已破坏当前调用栈状态。
真正难的是判断什么算“异常”——多数时候你以为要 panic 的地方，其实只是没想清楚错误边界。别让 recover 成为你逃避设计责任的快捷键。
