Go HTTP服务中panic不会导致进程崩溃，因标准库自动recover并记录日志，但不返回响应；必须在每个handler内用defer+recover手动捕获，区分error与panic，避免跨goroutine漏捕。
panic 会直接终止 HTTP 请求处理，但不会让整个服务宕机
Go 的 http.ServeHTTP 默认对每个请求启动独立 goroutine，单个请求 panic 只影响当前 goroutine。标准库已内置 recover 机制——它会在 http.serverHandler.ServeHTTP 中捕获 panic，并记录日志（log.Printf("http: panic serving %v: %v", c.remoteAddr, err)），然后关闭连接。这意味着：服务进程本身不会退出，其他请求照常处理。
但默认行为有明显缺陷：不返回可读错误响应、不记录堆栈、不触发监控告警、无法自定义错误码或格式。
- 不要依赖默认 panic 捕获，它只打日志，不返回 HTTP 响应体
- 所有 handler 函数入口必须手动包裹 recover，否则客户端收到空响应 + 连接重置
- recover 必须在 defer 中调用，且必须在 panic 发生的同一 goroutine 内
用 defer + recover 包裹每个 handler 是最稳妥的做法
不能只在顶层 middleware 里 recover —— 如果 panic 发生在中间件之后（比如业务逻辑里），而中间件没做 defer，就还是会漏掉。最保险的方式是：每个 http.HandlerFunc 都自己处理。
func myHandler(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
log.Printf("panic recovered in %s: %+v\n", r.URL.Path, err)
// 可选：上报 Sentry / Prometheus
}
}()
// 正常业务逻辑
db.QueryRow("SELECT ...").Scan(&user.ID) // 可能 panic（如空指针）
}
- recover() 返回 interface{}，建议用
fmt.Sprintf("%+v", err)打印完整堆栈 - 不要用
http.Error返回泛泛的 500，应根据 panic 类型区分：如*sql.ErrNoRows不该 panic，而是正常处理；真正该 panic 的是nil pointer dereference - 避免在 recover 里做耗时操作（如写磁盘、发 HTTP 请求），可能阻塞 goroutine
全局 panic 恢复：仅用于主 goroutine 和 init 阶段
main 函数或包初始化中发生的 panic 无法被 HTTP 层捕获，会导致整个进程退出。这类 panic 必须在 main() 入口处显式 recover：
立即学习“go语言免费学习笔记（深入）”；
func main() {
defer func() {
if r := recover(); r != nil {
log.Fatalf("FATAL PANIC in main: %+v", r)
os.Exit(1)
}
}()
http.ListenAndServe(":8080", mux)
}
- 这种 recover 仅兜底，不能替代 handler 级别的错误处理
- init 函数中 panic（如配置加载失败）无法被 main recover 捕获，需提前校验并 os.Exit(1)
- 第三方库（如某些 ORM 初始化）可能内部 panic，建议用
go run -gcflags="-l" ./main.go关闭内联，便于定位原始 panic 行号
别把 error 当 panic，也别把 panic 当 error
Go 的哲学是「error 用于可预期的失败，panic 用于不可恢复的程序错误」。常见误用：
- 数据库
sql.ErrNoRows是正常 error，不应 panic；但db == nil导致的 nil pointer dereference 才是 panic 级别 - JSON 解析失败（
json.Unmarshal返回 error）不该 panic；但传入nil指针给json.Unmarshal会 panic - 用
log.Fatal替代 panic 同样危险——它调用os.Exit(1)，直接杀进程
真正需要 panic 的场景极少：配置严重缺失（如未设置 DB DSN）、关键依赖未初始化、内存分配失败（极罕见）。其余一律走 error 返回 + handler 内部判断。
最易忽略的是：recover 只能捕获当前 goroutine 的 panic。如果业务代码启了新 goroutine（比如 go sendEmail()），它里面的 panic 无法被 handler 的 defer 捕获，必须在那个 goroutine 内部单独加 defer。
