Go中HTTP错误处理应优先用http.Error，它自动设状态码和Content-Type；自定义JSON错误需手动WriteHeader和Header.Set；Redirect不可替代错误响应；中间件中http.Error后必须return防双写。
Go中用http.Error返回标准HTTP错误最直接
绝大多数场景下，不需要手动写ResponseWriter.WriteHeader再Write，直接调用http.Error即可。它内部自动设置状态码、写入Content-Type: text/plain; charset=utf-8，并输出错误消息（支持中文）。
常见错误是自己拼接状态码和响应体，结果忘记设置Content-Length或Content-Type，导致前端解析异常或日志混乱。
func handler(w http.ResponseWriter, r *http.Request) {
if r.URL.Path != "/api/user" {
http.Error(w, "Not Found", http.StatusNotFound)
return
}
// ... 正常逻辑
}
自定义错误响应需手动控制Header和Write
当需要返回JSON错误（如{"error": "invalid token"}）、带Retry-After头，或复用已有结构体时，必须显式调用w.Header().Set()和w.WriteHeader()，且WriteHeader必须在Write之前调用——否则Go会自动补200 OK，后续再调WriteHeader就无效了。
-
WriteHeader只影响下一个Write，不能“回退”已写的响应体 - 若已调用
Write（哪怕只写了一个字节），再调WriteHeader会被忽略 - JSON错误建议设
Content-Type: application/json; charset=utf-8
func jsonError(w http.ResponseWriter, msg string, code int) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
w.WriteHeader(code)
json.NewEncoder(w).Encode(map[string]string{"error": msg})
}
http.Redirect不是错误处理，但常被误用作404/401跳转
http.Redirect本质是发3xx响应，不是错误响应。用它代替http.Error返回401或404，会导致客户端收到重定向而非明确错误状态，API调用方无法区分“未登录”和“重定向到登录页”，破坏REST语义。
只有明确需要浏览器跳转（如Web表单提交后跳转成功页）才用Redirect；API接口一律用http.Error或手动WriteHeader。
- 错误用法：
http.Redirect(w, r, "/login", http.StatusFound)代替http.Error(w, "Unauthorized", http.StatusUnauthorized) - 302跳转后，原请求的
Content-Type、body全丢失，无法携带错误详情
中间件中提前终止响应容易漏掉return
在middleware里检查token或权限时，如果调用http.Error但没return，后续handler仍会执行，可能造成双写响应（panic: “http: multiple response.WriteHeader calls”）。
这是Go HTTP最典型的运行时panic之一，尤其在嵌套中间件中容易遗漏。
func authMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !isValidToken(r) {
http.Error(w, "Forbidden", http.StatusForbidden)
return // ← 这行不能少！
}
next.ServeHTTP(w, r)
})
}
Go的HTTP错误处理本身很轻量，关键在于理解ResponseWriter是一次性写入流——状态码、头、正文的顺序和时机一旦错乱，就很难调试。真正麻烦的不是写错，而是忘了return或误以为Redirect能替代错误码。 
