如何使用Golang实现Web异常处理_Golang HTTP错误捕获与响应方法_技术教程

默认情况下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)
	})
}

使用时链式注册：

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())），这属于敏感信息泄露