Go语言中panic/recover非异常处理机制，仅用于不可恢复的致命错误；常规错误须用error返回，recover必须在defer中直接调用，HTTP服务应通过中间件全局捕获并返回500。
Go 语言没有传统意义上的“异常”（exception），panic 和 recover 不是为常规错误处理设计的，而是用于应对真正意外、不可恢复的程序状态——比如空指针解引用、切片越界、向已关闭 channel 发送数据等。把 panic 当成 Java 的 throw new RuntimeException() 来用，迟早踩坑。
什么时候该用 panic？
仅限初始化失败、配置严重错误、依赖服务完全不可用且无法降级等「程序根本无法继续运行」的场景。例如：
-
flag.Parse()后发现必填配置项为空，且无默认值可 fallback - 启动时读取证书文件失败，而 HTTPS 服务必须启用
- 全局单例初始化时数据库连接池创建失败，且无重试机制
注意：http.HandleFunc 回调里 panic 会导致整个 HTTP server 崩溃，除非你显式用 recover 拦截——但这属于兜底，不是推荐做法。
recover 必须在 defer 函数中直接调用
recover 只有在 defer 的函数体内被**直接调用**才有效。任何包装、间接调用都会失效：
立即学习“go语言免费学习笔记（深入）”；
func badRecover() {
defer func() {
// ❌ 错误：recover 被赋值给变量，再调用 → 失效
r := recover
r()
}()
panic("boom")
}
func goodRecover() {
defer func() {
// ✅ 正确：recover() 直接出现在 defer 函数体中
if r := recover(); r != nil {
log.Printf("recovered: %v", r)
}
}()
panic("boom")
}
常见错误还包括在 recover 前加了 return、或放在 goroutine 里调用——goroutine 是独立栈，主 goroutine 的 panic 不会传播过去，recover 自然无效。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
不要用 panic/recover 替代错误返回
业务逻辑中的可预期失败（如用户 ID 不存在、JSON 解析失败、网络超时）必须用 error 返回，而不是 panic。否则调用方无法区分「真崩溃」和「假异常」，也破坏了 Go 的显式错误流控制习惯。
-
os.Open("missing.txt")返回error，不是 panic —— 文件不存在是常态，不是 bug -
json.Unmarshal([]byte("{"), &v)返回error，语法错误应由上层决定是否忽略/重试/提示用户 - 若某函数内部用了
panic处理本该返回error的情况，它就违反了接口契约，下游无法安全使用
性能上，panic 触发时需遍历 goroutine 栈、生成 traceback，开销远高于 if err != nil 判断；而且一旦触发，当前 goroutine 栈会立即展开，所有 defer 按逆序执行——这可能干扰资源清理逻辑的预期顺序。
HTTP 中全局 panic 恢复的实用写法
如果你确实需要防止 handler panic 导致 server crash（比如第三方库内部 panic），应在中间件中统一 recover，但要注意两点：1）只捕获当前请求 goroutine 的 panic；2）恢复后仍要返回 500 并记录日志，不能静默吞掉。
func recoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("PANIC in %s %s: %v", r.Method, r.URL.Path, r)
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}
这个中间件必须放在链最外层（比如在 logging、auth 之后），否则内层中间件 panic 时外层还没执行到 defer。另外，它无法捕获异步 goroutine（如 go fn()）里的 panic——那些需要各自单独加 defer。
真正难的不是写 recover，而是判断「这个 panic 是该提前预防，还是该让程序挂掉以便暴露问题」。多数线上 panic 其实是未校验的空指针、未检查的类型断言、或并发写 map——这些都应该在开发阶段用 go vet、staticcheck 或单元测试揪出来，而不是靠 recover 救火。
