panic立即终止当前goroutine并执行defer，无recover则程序退出；recover仅在defer中直接调用才有效，且不能跨goroutine，不可用于常规错误处理。
panic 会立即终止当前 goroutine 的执行
调用 panic 不是抛出异常，而是触发运行时的“崩溃流程”：它会立刻停止当前 goroutine 中后续语句的执行，并开始逐层返回调用栈，对每个已执行的 defer 语句按后进先出顺序执行。如果没有任何 recover 拦截，程序最终会打印 panic 信息并退出。
常见误用场景包括：在 HTTP handler 中直接 panic("not found")，结果整个服务进程退出；或在循环中无条件 panic 导致无法清理资源。
-
panic接收任意接口类型参数，但建议传入error或带上下文的字符串（如panic(fmt.Errorf("failed to open %s: %w", path, err))） - 不要用
panic处理可预期的错误，比如文件不存在、网络超时——这些该用error返回 -
标准库中仅在真正不可恢复时使用
panic，例如json.Unmarshal遇到非法结构体字段时 panic，因为此时程序逻辑已错乱
recover 必须在 defer 函数中调用才有效
recover 只有在 defer 函数中被直接调用时才能捕获当前 goroutine 的 panic。如果把它包在另一个函数里再调用（比如 defer func() { safeRecover() }()），而 safeRecover 内部调用 recover()，那就捕获不到——因为此时 panic 已经离开原始调用栈上下文。
func risky() {
defer func() {
if r := recover(); r != nil {
log.Printf("recovered from panic: %v", r)
}
}()
panic("something went wrong")
}
- 必须是
defer匿名函数体内直接写recover()，不能间接调用 -
recover()返回interface{}，通常需做类型断言，例如r, ok := recover().(error) - recover 后程序不会“继续执行 panic 后的代码”，而是从
defer函数返回后继续执行 panic 发生点之后的外层逻辑（即 panic 调用所在函数的后续语句不会执行）
HTTP server 中全局 panic 恢复要靠中间件或自定义 ServeHTTP
默认 http.ServeMux 不捕获 handler 内 panic，一旦 panic 就会导致当前连接关闭、日志输出，但不会影响其他请求。不过大量 panic 可能掩盖真实问题，且无法统一记录或返回友好响应。
立即学习“go语言免费学习笔记（深入）”；
正确做法是在 handler 外层加 recover 逻辑，最稳妥的是实现自定义 http.Handler：
type recoverHandler struct {
next http.Handler
}
func (h *recoverHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
log.Printf("PANIC in %s %s: %v", r.Method, r.URL.Path, r)
}
}()
h.next.ServeHTTP(w, r)
}
- 不要在每个 handler 里重复写 defer+recover，应统一抽象为中间件或包装器
- 注意：recover 无法跨 goroutine 生效，所以若 handler 启了新 goroutine 并在其中 panic，主 goroutine 的 recover 捕获不到
- 某些框架（如 Gin）自带
gin.Recovery()中间件，本质就是上述模式的封装
recover 不是 try/catch，别试图用它做流程控制
Golang 的设计哲学是“错误是值”，panic/recover 是为真正异常情况保留的逃生通道，不是控制流工具。滥用会导致代码难以推理、性能下降（panic 堆栈展开开销大）、测试困难。
- 不要写
if err != nil { panic(err) }然后靠 recover 把 err 转成 HTTP 状态码——直接返回err并由上层处理更清晰 - benchmark 显示，触发 panic 的代价比返回 error 高 100 倍以上，高频路径务必避免
- Go 1.22+ 对 panic 性能有所优化，但语义没变：它仍表示“你本不该走到这里”
recover 只对同 goroutine 有效，且只对最近一次未被捕获的 panic 生效。多 goroutine 协作时，panic 的传播边界比想象中更窄。 
