Go中http.Client必须显式设置超时，否则DefaultClient会无限阻塞；需区分网络错误与HTTP状态码，用自定义error类型携带上下文，并对可重试错误实施指数退避重试。
Go 中 http.Client 超时与连接错误必须显式控制
Go 的 http.DefaultClient 没有默认超时，一旦下游服务卡住或网络异常，http.Do() 会无限阻塞 goroutine。这不是“偶尔出错”，而是生产环境必现的资源泄漏点。
正确做法是始终使用自定义 http.Client，并设置 Timeout 或更精细的 Transport 级配置：
-
Timeout控制整个请求生命周期（DNS + 连接 + 写请求 + 读响应） - 若需分别控制连接和读写，改用
Transport的DialContext、ResponseHeaderTimeout等字段 - 避免在高并发场景复用未设超时的全局 client，否则一个慢接口拖垮整条链路
client := &http.Client{
Timeout: 5 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
},
}区分 error 类型：网络错误 ≠ HTTP 状态码错误
调用外部 API 后拿到的 err 和 resp.StatusCode 是两回事，混为一谈会导致逻辑漏洞。比如 resp.StatusCode == 500 是服务端错误，而 err != nil 很可能是 DNS 失败、连接被拒、TLS 握手失败等底层问题。
典型误判场景：
立即学习“go语言免费学习笔记（深入）”；
- 直接检查
if err != nil { return err }就返回，却忽略resp可能为nil—— 此时再读resp.StatusCode会 panic - 看到
resp.StatusCode >= 400就认为是业务错误，但没处理io.EOF或net/http: request canceled这类可重试的临时错误 - 把
url.Error当作普通 error 忽略其Err字段里的底层原因（如*net.OpError）
resp, err := client.Do(req)
if err != nil {
var urlErr *url.Error
if errors.As(err, &urlErr) && urlErr.Err != nil {
// 检查底层错误是否是 net.OpError、context.DeadlineExceeded 等
if netErr, ok := urlErr.Err.(*net.OpError); ok && netErr.Op == "dial" {
log.Printf("network dial failed: %v", netErr)
}
}
return fmt.Errorf("http call failed: %w", err)
}
defer resp.Body.Close()
if resp.StatusCode >= 400 {
body, _ := io.ReadAll(resp.Body)
return fmt.Errorf("api returned %d: %s", resp.StatusCode, string(body))
}
封装外部调用时，用自定义 error 类型携带上下文
只返回 fmt.Errorf("failed to call X: %w", err) 会让上层无法判断错误性质（是否可重试？是否要告警？是否要降级？）。Go 推荐用可识别的 error 类型做语义区分。
建议为每个外部依赖定义一组 error 变量或类型：
-
ErrServiceUnavailable：对应 503、连接拒绝、context.Canceled -
ErrBadRequest：明确是客户端参数错误（400/422），不应重试 - 实现
Is()方法，方便上层用errors.Is(err, ErrServiceUnavailable)判断 - 避免在 error 消息里拼接敏感字段（如 token、完整 URL），应通过结构体字段传递元数据
type ServiceError struct {
Code int
Message string
Endpoint string
IsRetryable bool
}
func (e *ServiceError) Error() string {
return fmt.Sprintf("service %s failed with %d: %s", e.Endpoint, e.Code, e.Message)
}
var ErrServiceUnavailable = &ServiceError{IsRetryable: true, Code: 503}
// 使用示例
if resp.StatusCode == 503 {
return &ServiceError{
Code: 503,
Message: "service unavailable",
Endpoint: req.URL.String(),
IsRetryable: true,
}
}
重试逻辑不能只靠 for + time.Sleep
简单循环加固定延时（如 time.Sleep(100 * time.Millisecond)）在真实场景中极易引发雪崩：多个服务同时失败 → 同步重试 → 请求洪峰打垮下游。
必须引入退避策略和终止条件：
- 用
backoff.Retry（github.com/cenkalti/backoff/v4）或golang.org/x/time/rate控制节奏 - 重试次数上限建议 ≤ 3，指数退避起始值 ≥ 100ms（如 100ms → 200ms → 400ms）
- 仅对特定错误重试：
net.OpError、context.DeadlineExceeded、503/504，**不重试 400/401/404** - 重试时更新
req.Context()，避免原 context 已 cancel 却还在发请求
最常被忽略的一点：重试不等于“换个时间再试一次”，而是“换一种方式继续”。比如第一次用 JSON POST 失败，第二次可尝试带 X-Retry: true header 或切换到备用 endpoint。
