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-Afterheader） - 不要仅靠状态码决定是否重试：还需检查
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)。
