如何在Golang中处理HTTP状态码错误_Golang状态码判断与处理技巧

go 的 http.Client.Do() 不会因非 2xx 状态码返回 Error，需显式检查 resp.StatusCode ≥ 300；应先处理网络错误（err != nil），再判断状态码，并按 4xx/5xx 分类处理，结合 Checkredirect 控制重定向。

判断 http.Response.StatusCode 是否表示错误

Go 的 http.Client.Do() 不会自动把非 2xx 状态码转为 error，它只在底层连接失败、超时或无法解析响应时返回 error。也就是说，404、500、401 这类响应会正常返回 *http.Response，但 resp.StatusCode 已经不是成功状态。

正确做法是显式检查状态码范围：

if resp.StatusCode < 200 || resp.StatusCode >= 300 {     // 处理业务错误，比如记录日志、封装自定义错误等     return fmt.Errorf("HTTP %d: %s", resp.StatusCode, http.StatusText(resp.StatusCode)) }

• http.StatusText(code) 能安全转成可读文本（如 404 → "Not Found"），比硬编码字符串更可靠
• 别只检查 != 200：有些 API 正常返回 201 Created 或 204 No Content
• 如果调用的是 restful 接口，建议按语义分组处理：比如 4xx 归为客户端错误（可重试需谨慎），5xx 归为服务端错误（通常应重试）

用 http.Client.CheckRedirect 捕获重定向失败

默认情况下，http.Client 会自动跟随 301/302 重定向，直到达到最大跳转次数（默认 10 次），然后才返回最终响应。但你可能想在重定向链中某一步就中断，比如发现跳到了不可信域名，或遇到了 307 Temporary Redirect 却不想自动带 body 重发。

通过 CheckRedirect 回调可以干预：

立即学习“go语言免费学习笔记（深入）”；

client := &http.Client{     CheckRedirect: func(req *http.Request, via []*http.Request) error {         if len(via) >= 3 {             return errors.New("too many redirects")         }         if req.URL.Host != "api.example.com" {             return fmt.Errorf("redirect to unauthorized host: %s", req.URL.Host)         }         return nil     }, }

• 回调在每次重定向前触发，via 是已发生的请求切片（含原始请求），可用于审计路径
• 若返回非 nil error，整个 Do() 调用将立即返回该 error，且 resp 为 nil
• 注意：这个机制不捕获 304 Not Modified，它不算重定向，而是直接复用缓存响应

区分网络错误与 HTTP 状态码错误

常见误区是把 err != nil 和 “HTTP 错误” 混为一谈。实际上，err 只反映传输层问题，比如 dns 失败、连接拒绝、TLS 握手失败、读取超时；而 resp.StatusCode 是应用层协议字段，两者必须分开处理。

典型错误写法：

// ❌ 错误：把网络错误和 404 当作同一类 if err != nil || resp.StatusCode != 200 {     log.Fatal(err) }

正确处理顺序应该是：

resp, err := client.Do(req) if err != nil {     // 处理连接失败、超时、证书错误等     return fmt.Errorf("network error: %w", err) } defer resp.Body.Close()  if resp.StatusCode < 200 || resp.StatusCode >= 300 {     // 处理 4xx/5xx 等语义错误     return fmt.Errorf("HTTP %d: %s", resp.StatusCode, http.StatusText(resp.StatusCode)) }

• 务必先判 err，再用 resp；否则 resp 可能为 nil，panic
• resp.StatusCode 在 err == nil 时一定有效，即使响应体为空（如 204）
• 某些代理或中间件可能返回 0 状态码（极少见），此时 http.StatusText(0) 返回空字符串，需额外防御

封装可重试的 HTTP 请求并分类响应错误

生产环境常需对临时性错误（如 502 Bad gateway、503 Service Unavailable）做指数退避重试，但对 400 Bad Request 或 401 Unauthorized 重试无意义。因此建议按状态码语义分层封装错误类型。

示例结构：

type HTTPError struct {     StatusCode int     StatusText string     IsTemporary bool }  func (e *HTTPError) Error() string {     return fmt.Sprintf("HTTP %d %s", e.StatusCode, e.StatusText) }  func isTemporaryStatusCode(code int) bool {     return code >= 500 && code < 600 || code == 429 }

• 429 Too Many Requests 虽属 4xx，但属于临时限流，适合重试（配合 Retry-After header）
• 不要仅靠状态码决定是否重试：还需检查 resp.Header.Get("Connection") == "close" 或是否有 Retry-After 字段
• 重试逻辑中记得克隆 *http.Request（因为 body 可能已被读取），用 req.Clone(req.Context())

真正容易被忽略的是：即使你封装了完美的错误分类，如果没关闭 resp.Body，连接会一直占用，导致 net/http: connection refused 或 too many open files —— 所有分支都得确保 Close() 被调用，哪怕只是 io.copy(io.Discard, resp.Body)。