如何使用Golang处理HTTP请求错误_GolangHTTP响应错误处理示例

HTTP请求失败时resp可能为nil，须先判空再访问；需区分网络层、TLS层、HTTP语义层错误，用errors.As精准判断；StatusCode≥400仍需读取响应体，但须用context和MaxBytesReader限流限超时。

HTTP请求失败时，resp 可能为 nil，必须先判空再读取

Go 的 http.DefaultClient.Do() 在网络不可达、DNS失败、连接超时等情况下会直接返回 err != nil，此时 resp 是 nil。如果跳过判空就调用 resp.StatusCode 或 resp.Body.Close()，会触发 panic。

• 永远在 if err != nil 后加 return 或显式处理，不要继续执行后续依赖 resp 的逻辑
• 即使 err == nil，也不能假设请求“成功”——HTTP 状态码如 404、500 仍属于服务端错误，需单独检查 resp.StatusCode
• 务必调用 resp.Body.Close()（在 err == nil 且 resp != nil 时），否则连接不会复用，容易耗尽文件描述符

区分三类错误：网络层、TLS层、HTTP语义层

Go 的 HTTP 错误不是单一类型，不同错误需要不同策略：

• 网络错误：如 dial tcp: i/o timeout、connection refused，通常来自 net.OpError，适合重试（配合指数退避）
• TLS 错误：如 x509: certificate signed by unknown authority，多因证书配置问题，重试无意义，应检查 http.Client.Transport.TLSClientConfig
• HTTP 语义错误：如 401 Unauthorized、429 Too Many Requests，需解析响应体（如 JSON error message）并按业务逻辑处理，而非当网络故障重试

用 errors.As 提取底层错误类型做精准判断

直接用 strings.Contains(err.Error(), "timeout") 不可靠——错误信息可能随 Go 版本变化。推荐用 errors.As 匹配具体错误类型：

var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
    // 处理超时，例如记录指标或触发重试
}
var urlErr *url.Error
if errors.As(err, &urlErr) && urlErr.Err != nil {
    // 检查 urlErr.Err 是否为 *net.OpError 等
}

• net.Error 接口提供 Timeout() 和 Temporary() 方法，比字符串匹配更健壮
• url.Error 封装了原始错误，常用于 DNS 解析失败或 URL 格式错误
• 避免对 err.Error() 做子串匹配，尤其在线上环境——它不属于 API 合约，随时可能调整

响应体读取前必须检查 resp.StatusCode，且用 io.ReadAll 配合 context 控制读取时限

即使 resp.StatusCode >= 400，服务端仍可能返回有意义的错误体（如 {"error": "invalid_token"}）。但直接调用 io.ReadAll(resp.Body) 有风险：

• 若服务端未关闭连接或发送超大响应体，会阻塞甚至 OOM
• 应结合 context.WithTimeout 限制整个读取过程，而不是只限请求发起
• 始终用 defer resp.Body.Close()（在确认 resp != nil 后立即 defer）

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
body, err := io.ReadAll(http.MaxBytesReader(ctx, resp.Body, 1<<20)) // 限制最大 1MB
if err != nil {
    // 处理读取超时或过大响应
}

实际处理中，最易被忽略的是：**把 4xx/5xx 当作网络错误统一重试**，结果导致鉴权失败反复刷 token，或 429 被持续加重。状态码语义必须由业务代码显式分支处理，不能交给通用重试逻辑兜底。