如何使用Golang实现HTTP客户端错误处理_Golang请求响应异常管理

http请求失败需同时检查resp和err：err非nil表示网络层错误，resp.StatusCode非2xx表示服务端错误；超时应优先用context.WithTimeout；重试须区分幂等性，仅对5xx或网络超时等错误进行指数退避。

HTTP请求失败时，resp 为 nil，但 err 不一定代表网络错误

go 的 http.DefaultClient.Do() 在多数异常下（如 dns 解析失败、连接超时、TLS 握手失败）会返回非 nil 的 err，同时 resp 为 nil；但遇到服务端返回 4xx/5xx 状态码时，err 是 nil，而 resp.StatusCode 已非 2xx。这是最常被忽略的分水岭。

实际处理必须同时检查两个值：

resp, err := http.DefaultClient.Do(req) if err != nil {     // 这里是真正的请求失败：超时、拒绝连接、证书错误等     log.Printf("request failed: %v", err)     return } defer resp.Body.Close() 
if resp.StatusCode < 200 || resp.StatusCode >= 300 { // 这里是服务端明确返回了错误响应，比如 404、502、401 body, _ := io.ReadAll(resp.Body) log.Printf("server error %d: %s", resp.StatusCode, string(body)) return }

超时控制必须用 context.WithTimeout，不能只设 http.Client.Timeout

http.Client.Timeout 只作用于整个请求生命周期（从连接到读完 body），但它无法中断正在阻塞的 DNS 查询或 TLS 握手。真正可靠的方式是用 context 控制，尤其在高并发或不可信网络中。

• http.Client.Timeout 对已建立连接后的读写有效，但对 dial 阶段无强制力
• context.WithTimeout 能中断 net.DialContext、TLS 协商、甚至 Read 调用
• 若同时设置两者，以更早触发的 timeout 为准

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() 
req, _ := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca", nil) resp, err := http.DefaultClient.Do(req) // 此时 err 可能是 context.DeadlineExceeded

重试逻辑不能直接套用 for + time.Sleep，要避开幂等性陷阱

对 POST/PUT 等非幂等请求盲目重试，可能造成重复提交。正确做法是：仅对可安全重试的错误类型重试，并配合指数退避。

立即学习“go语言免费学习笔记（深入）”；

• 可重试错误包括：context.DeadlineExceeded、io.EOF、net.OpError（如 connection refused）、http.ErrUseLastResponse
• 不可重试错误包括：状态码 400、401、403、422 及所有 4xx（客户端错误）
• 避免在重试中重复读取 req.Body —— 若是 bytes.Reader 或 strings.Reader，需每次重建；若是文件或流，需支持 Seek

简单判断是否值得重试：

if err != nil {     var netErr net.Error     if errors.As(err, &netErr) && netErr.Timeout() {         // 可重试的超时     } } else if resp.StatusCode >= 500 && resp.StatusCode < 600 {     // 服务端错误，通常可重试 }

自定义 http.Transport 是管理连接复用与证书校验的关键入口

默认的 http.DefaultTransport 在长连接、代理、自签名证书等场景下往往不够用。错误处理的健壮性很大程度取决于 transport 层配置。

• MaxIdleConns 和 MaxIdleConnsPerHost 过低会导致频繁建连，放大超时风险
• IdleConnTimeout 和 TLSHandshakeTimeout 应显式设置，避免连接卡死
• 对接内部服务时，常需绕过证书校验：TLSClientConfig: &tls.Config{InsecureSkipVerify: true}，但务必限定 host 范围，而非全局启用

tr := &http.Transport{     MaxIdleConns:        100,     MaxIdleConnsPerHost: 100,     IdleConnTimeout:     30 * time.Second,     TLSHandshakeTimeout: 10 * time.Second,     TLSClientConfig: &tls.Config{         InsecureSkipVerify: true, // 仅用于测试或内网     }, } client := &http.Client{Transport: tr}

实际项目中，错误边界往往藏在 transport 初始化、context 生命周期管理、以及对 resp.StatusCode 的条件分支里。少有人出错在“怎么发请求”，多栽在“以为请求失败就等于 err != nil”。