Go中解析http.Client错误需分层处理：先判网络/传输层错误（如超时、连接失败），再查HTTP协议层状态码，最后捕获响应体读取错误；err!=nil时不可信任resp，仅err==nil才安全使用resp字段并defer关闭Body。
Go 中解析 http.Client 返回的 error，关键不是“统一判断 err != nil 就报错”，而是分层识别错误来源、性质和可恢复性。错误类型不同，处理方式差异很大——有些该重试，有些该告警，有些该立刻返回用户。
区分三类错误源头
Go 的 HTTP 错误大致来自三个层面，必须逐层判断：
-
网络/传输层错误：如 DNS 失败、连接超时、TLS 握手失败、服务器不可达。这类 error 通常实现了
net.Error接口，可通过errors.Is(err, context.DeadlineExceeded)或netErr.Timeout()判断。 -
HTTP 协议层错误：请求已发出且收到响应，但状态码非预期（如 404、500）。此时
err == nil，resp非 nil，必须检查resp.StatusCode。 -
响应体读取错误：比如
io.ReadAll(resp.Body)过程中发生网络中断、解压失败或流截断。这类错误发生在resp.Body.Close()之前，需单独捕获并处理。
正确判断 err 是否可信任 resp
只要 err != nil，就不能假设 resp 有效——它可能为 nil，也可能部分初始化（例如有 Header 但无 Body）。安全写法是：
- 先判断
err，不为 nil 就直接处理或返回，不要碰resp； - 只有
err == nil时，才可放心使用resp.StatusCode、resp.Header等字段； - 无论状态码如何，只要
resp != nil，都必须调用defer resp.Body.Close()（注意：要放在err检查之后）。
常见错误模式与对应处理
以下错误应区别对待：
-
context.DeadlineExceeded或net.ErrTimeout：超时，适合加退避重试（尤其对 503、504）； -
net.OpError+"connection refused"或"no such host"：服务未启动或域名错误，一般不重试； -
tls.CertificateVerificationError：证书问题，需检查 TLS 配置或跳过验证（仅测试环境）； - 状态码
401/403：鉴权失败，应检查 token 或权限配置； - 状态码
429：被限流，建议提取Retry-Afterheader 并延迟重试； - 状态码
5xx：服务端异常，可考虑有限次数重试（如 2 次），避免雪崩。
推荐封装一个统一错误检查函数
避免每个请求都重复写一堆 if-else，可封装类似：
func CheckHTTPResp(resp *http.Response, err error) error {
if err != nil {
var netErr net.Error
if errors.As(err, &netErr) {
if netErr.Timeout() {
return fmt.Errorf("request timeout: %w", err)
}
}
return fmt.Errorf("network error: %w", err)
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
body, _ := io.ReadAll(resp.Body)
return fmt.Errorf("http %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
}
return nil
}
调用时：if err := CheckHTTPResp(resp, err); err != nil { ... }
基本上就这些。核心是别把 “请求没发出去” 和 “服务端说错了” 当成一回事处理。
