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 内部使用）：
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 成为你逃避设计责任的快捷键。