如何在Golang中处理网络错误_Golang net/http 错误处理方法

http.Do失败需同时检查err和resp.StatusCode:err!=nil为网络层错误,err==nil但StatusCode>=400为服务端错误;必须检查状态码并关闭resp.Body。

判断 http.Do 是否失败不能只看返回值是否为 nil

很多初学者以为只要 resp 不是 nil 就代表请求成功,其实不然。http.Do 在底层连接失败、DNS 解析失败、TLS 握手失败等情况下会直接返回错误,respnil;但若请求发出去了、服务器返回了非 2xx 状态码(比如 404、500),resp 依然非 nil,而 errnil —— 这时你必须手动检查 resp.StatusCode

  • err != nil:说明网络层或协议层出问题(如超时、拒绝连接、证书错误)
  • err == nil && resp.StatusCode >= 400:说明服务端返回了错误响应,属于业务/语义错误
  • 两者都需处理,缺一不可

net.Error 类型断言能区分超时与拒绝连接

err != nil 时,常见错误类型包括 *url.Error*net.OpErrornet.DNSError 等。其中最实用的是用 net.Error 接口判断是否超时或临时不可达:

if urlErr, ok := err.(*url.Error); ok {
    if netErr, ok := urlErr.Err.(net.Error); ok {
        if netErr.Timeout() {
            log.Println("请求超时")
        }
        if netErr.Temporary() {
            log.Println("临时性网络错误,可重试")
        }
    }
}
  • Timeout() 返回 true 表示超时(含 context.DeadlineExceeded
  • Temporary() 对 DNS 失败、连接被拒、IO timeout 等多数网络抖动场景返回 true,适合做指数退避重试
  • 注意:net.Error 不涵盖 HTTP 协议级错误(如 401),它只管底层连接

使用 context.WithTimeout 控制请求生命周期比设置 Client.Timeout 更灵活

http.Client.Timeout 是全局兜底,一旦设死就无法 per-request 调整;而 context 可在调用链任意位置注入取消信号,更适合真实场景:

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com/data", nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
    // 此处 err 可能是 context.DeadlineExceeded 或 net.OpError
    if errors.Is(err, context.DeadlineExceeded) {
        log.Println("上下文超时,不是网络故障")
    }
    return
}
  • errors.Is(err, context.DeadlineExceeded) 比类型断言更安全(兼容 Go 1.13+)
  • 若请求本身已携带 context(如 HTTP handler 的 r.Context()),直接复用,避免新建
  • Client.Timeout 仅作用于整个请求周期(从 Dial 到读完 body),不覆盖 DNS 查询耗时;而 context 覆盖全部

读取 resp.Body 前必须检查 StatusCode,且务必 Close

即使 err == nil,也要先检查状态码再决定是否读 body,否则可能把 404 页面当成正常数据解析;同时,无论成功失败,resp.Body 都必须关闭,否则连接不会复用,容易触发 too many open files

if resp.StatusCode < 200 || resp.StatusCode >= 300 {
    log.Printf("HTTP %d: %s", resp.StatusCode, resp.Status)
    resp.Body.Close() // 必须关!
    return
}

defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
// ... 处理 body
  • 不要在 if err != nil 分支里才 Close():因为 err == nilBody 仍可能非空且需释放
  • defer 放在检查状态码之后,确保不遗漏
  • 如果后续要用 resp.Body 流式处理(如解压、解密),也得自己控制 Close 时机,不能无脑 defer
实际项目中,最容易被忽略的是「服务端返回 5xx 时没做重试」和「忘记关 Body 导致连接池耗尽」——这两点比语法细节更容易拖垮线上服务。