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”。
