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 {……}
基本上就这些。核心是别把“请求没发出去”和“服务端说错了”当成一回事处理。
