panic 和 recover 不是异常处理机制，而是应对不可恢复崩溃的紧急制动手段；它们不能替代 error，仅限初始化失败、HTTP 处理器兜底等少数场景使用。
panic 和 recover 不是 Go 的“异常处理机制”，而是用于应对真正不可恢复的崩溃场景的紧急制动与兜底手段。 它们不能替代 error 返回值，也不该出现在常规业务逻辑中——一旦滥用，会让错误流变得隐晦、难以调试、性能下降，甚至掩盖真正的 bug。
panic 是什么：不是“抛异常”，而是“程序已无法继续”
当 Go 遇到运行时错误（如 nil 指针解引用、切片越界、向已关闭 channel 发送数据）或你主动调用 panic() 时，当前 goroutine 立即停止执行，所有已注册的 defer 函数按后进先出顺序触发，然后 panic 向上蔓延。若无人拦截，进程退出并打印堆栈。
- 它不支持 try/catch 那样的嵌套捕获，也没有 finally 语义
-
panic的参数类型是interface{}，常见为string或error，但框架中建议统一用error方便后续处理 - 调用
os.Exit()会跳过所有defer和recover，它就是硬退出
recover 怎么用：必须在 defer 里，且只能捕获本 goroutine
recover() 只有在 defer 函数体内直接调用才有效；写在普通函数体里、或者 defer 中再套一层普通函数调用，都会失效。
- 它不会“修复”问题，只是让程序有机会做清理、记录日志、返回错误响应
- 每个 goroutine 的 panic 必须由自己内部的
defer+recover捕获；外层 goroutine 的recover对子 goroutine 的 panic 完全无效 - 典型错误写法：
defer func() { recover() }()—— 这能运行但永远捕不到，因为没接返回值；正确写法是if r := recover(); r != nil { ... }
什么时候该用：只限初始化失败、HTTP 处理器兜底等少数场景
90% 的错误都应该走 error 返回路径。只有当你确认“这个错误发生，程序就绝对不该再往前走一步”时，才考虑 panic。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 合理场景：服务启动时配置加载失败、数据库连接池初始化失败、关键依赖未注入
- ✅ HTTP 中间件中包裹 handler：防止单个请求 panic 导致整个 server 崩溃
- ❌ 错误场景：
divide(a, b)中 b==0 就panic；应该返回(result, error) - ❌ 错误场景：在库函数里对用户输入做校验失败就 panic —— 调用方无法预期，也无法防御
recover 后怎么处理 panic 值：别只打印，要转化、要记录、要区分类型
捕获到的 r 是 interface{}，直接 fmt.Println(r) 很难排查问题。你应该做类型断言，并按需转成标准 error。
defer func() {
if r := recover(); r != nil {
var err error
switch x := r.(type) {
case string:
err = errors.New(x)
case error:
err = x
default:
err = fmt.Errorf("panic: %v", r)
}
log.Error("request panic", "err", err, "stack", debug.Stack())
http.Error(w, "Internal Server Error", 500)
}
}()
- 不判断类型直接强转
r.(error)可能 panic 二次崩溃 - 建议配合
debug.Stack()记录完整堆栈，否则只看到 panic 字符串，定位困难 - recover 后函数不会“回到 panic 那行继续执行”，而是从 defer 结束后往下走 —— 所以 panic 后面的代码永远不会运行
最常被忽略的一点：recover 不是安全网，而是最后一道手动刹车。它掩盖不了设计缺陷，也救不了资源泄漏。真要健壮，得靠清晰的 error 分层、合理的 panic 边界、以及每个 goroutine 自己负责自己的 recover。
