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。