默认情况下http handler中panic会导致服务崩溃，因http.ServeMux和http.Server不recover panic，需用中间件统一defer recover并返回规范错误响应。
HTTP handler 中 panic 会直接导致服务崩溃吗
默认情况下，http.ServeMux 和 http.Server 不会 recover panic，一旦 handler 函数内发生未捕获的 panic，当前 goroutine 会终止，连接可能被意外关闭，日志里只留下类似 http: panic serving 127.0.0.1:54321: runtime Error: invalid memory address 的错误，而客户端收到的是空响应或连接重置。
这不是“异常处理”，是服务稳定性缺口。必须主动包裹 handler 才能拦截 panic 并返回有意义的 HTTP 状态码。
- 不要依赖全局
recover()—— 它只对当前 goroutine 有效，且必须在 defer 中调用 - 推荐在中间件层统一处理，而非每个 handler 内重复写 defer/recover
- 注意：recover 只能捕获同一 goroutine 中的 panic，无法跨 goroutine 捕获（比如你在 goroutine 里启了个异步任务并 panic，主 handler 不会感知）
用中间件封装 recover 实现统一错误响应
最常用也最可控的方式，是写一个 recoveryMiddleware，它 wrap 原始 http.Handler，在 ServeHTTP 中 defer recover。
func recoveryMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { defer func() { if err := recover(); err != nil { http.Error(w, "internal Server Error", http.StatusinternalServerError) log.printf("PANIC in %s %s: %+v", r.Method, r.URL.Path, err) } }() next.ServeHTTP(w, r) }) }使用时链式注册：
立即学习“go语言免费学习笔记（深入）”；
mux := http.NewServeMux() mux.HandleFunc("/api/user", userHandler) http.ListenAndServe(":8080", recoveryMiddleware(mux))- 注意：
http.Error()会设置状态码并写入响应体，之后不能再写 header 或 body，所以 recover 后务必停止后续逻辑 - 如果需要返回 jsON 错误（如
{"error": "Internal Server Error"}），别用http.Error，改用手动设置w.WriteHeader()+json.NewEncoder(w).Encode(...) - 该中间件不处理
net/http自身错误（如超时、连接关闭），那些走不到你的 handler，需靠Server.ErrorLog或自定义Server.ConnContext配合监控
业务逻辑中显式返回 error 并转为 HTTP 响应
比起依赖 panic，更推荐在 handler 内部做错误判断，用标准 Go error 流程控制流程，并映射到对应 HTTP 状态码。
例如数据库查询失败、参数校验不通过、资源不存在等，都应返回具体 error，而不是 panic。
func userHandler(w http.ResponseWriter, r *http.Request) { idStr := r.URL.Query().Get("id") id, err := strconv.ParseInt(idStr, 10, 64) if err != nil { http.Error(w, "Invalid user ID", http.StatusbadRequest) return } user, err := db.FindUserByID(id) if err != nil { if errors.Is(err, sql.ErrNoRows) { http.Error(w, "User not found", http.StatusNotFound) return } http.Error(w, "Database error", http.StatusInternalServerError) return } w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(user) }- 避免把所有 error 都映射成
http.StatusInternalServerError；区分400（客户端错）、404（资源不存在）、401/403（权限问题）、500（服务端不可控错） - 不要在 handler 外层用
if err != nil { panic(err) }—— 这等于把可控错误变成不可控 panic - 若业务 error 类型多，可定义 error wrapper（如
type AppError Struct { Code int; Msg String }），统一格式化响应
如何记录错误同时不影响响应结构
日志和响应要解耦：错误响应面向客户端，日志面向运维和调试。不能因为加了 log 就改变 HTTP 状态或 body。
- 用
log.Printf或结构化日志库（如zap）记录完整上下文：method、path、query、body（注意脱敏）、error stack、耗时 - 不要在
defer func()中调用w.Write()—— 此时 response 可能已提交，会 panic 报http: multiple response.WriteHeader calls - 若需在 recover 后返回结构化 JSON，确保
w.Header().Set("Content-Type", "application/json")在 write 前调用，且仅调用一次 - 生产环境禁用
panic输出 stack 到响应体（如fmt.Fprint(w, debug.Stack())），这属于敏感信息泄露