HTTP客户端超时必须显式设置，Go默认无超时，易致goroutine泄漏；应使用自定义Client配合Timeout、Transport细粒度超时或context.WithTimeout控制请求生命周期。
HTTP客户端超时必须显式设置，Go默认不设限
Go 的 http.DefaultClient 和零值 http.Client{} 都**没有默认超时**——发起请求后可能无限期阻塞在 DNS 解析、连接建立、TLS 握手或响应读取阶段。生产环境一旦遇到网络抖动、服务不可达或远端 hang 住，就会导致 goroutine 泄漏和资源耗尽。
正确做法是始终用自定义 http.Client，并通过 Timeout 或更细粒度的字段控制各阶段时限：
-
Timeout是总超时（从Do()调用开始计时），覆盖 DNS、连接、TLS、发送请求、读取响应头和响应体全过程 - 若需独立控制连接建立或响应读取时间，应使用
Transport的DialContext和ResponseHeaderTimeout等字段，而非只依赖Timeout - 避免混用
Timeout和 Transport 级超时，否则行为不可预测（例如Timeout先触发会中断正在进行的 TLS 握手，错误类型可能是net/http: request canceled (Client.Timeout exceeded while awaiting headers)）
推荐用 context.WithTimeout 控制请求生命周期
比单纯设 Client.Timeout 更灵活：可动态传入取消信号、与上游调用链超时对齐、支持手动 cancel，且能清晰区分“用户主动取消”和“超时失败”。
实际写法如下：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
<p>req, err := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>", nil)
if err != nil {
return err
}</p><p>resp, err := http.DefaultClient.Do(req)
if err != nil {
// 注意：err 可能是 <em>url.Error，其 Err 字段才是真实原因
// 例如：err.(</em>url.Error).Err == context.DeadlineExceeded
return err
}
defer resp.Body.Close()</p>关键点：
- 必须调用
cancel()，否则 ctx 会泄漏；defer cancel()是最简保障 - 不要复用同一个
context.Context多次发起请求——它是一次性的，第二次Do()会立即返回context.Canceled - 如果请求本身已带上游 ctx（如 HTTP handler 的
r.Context()），直接基于它派生子 ctx，别用context.Background()
Transport 层超时要按需启用，不是所有场景都需要
当业务要求更精细的控制（比如允许长连接但限制单次响应读取时间），才需要配置 http.Transport。常见组合：
-
IdleConnTimeout：控制空闲连接保活时长，防连接池堆积（建议设为 30–90s） -
ResponseHeaderTimeout：从连接建立完成到收到响应头的上限，适合防远端卡在生成 header 阶段 -
TLSHandshakeTimeout：仅影响 HTTPS 请求，防止 TLS 握手慢拖累整体（设为 10s 内较稳妥） - 慎用
DialTimeout（已弃用），改用DialContext+net.Dialer.Timeout
示例 Transport 配置：
transport := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second,
ResponseHeaderTimeout: 3 * time.Second,
IdleConnTimeout: 60 * time.Second,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
}
<p>client := &http.Client{
Transport: transport,
Timeout: 10 * time.Second, // 总兜底，仍需保留
}</p>测试超时是否生效的关键检查点
光写代码不验证等于没设。最容易被忽略的是：本地 mock 服务无法触发真实超时路径（比如 loopback 往往瞬间返回）。验证要点：
- 用
net.Listener启一个故意不写响应的 server（只 accept 不 write），测连接后卡住的场景 - 用
golang.org/x/net/proxy配一个无响应的 SOCKS5 代理，测 DNS+连接阶段超时 - 抓包看 TCP 层是否真断连（如
tcpdump观察 FIN 包），避免误判为应用层“假超时” - 日志中检查错误类型：
context.DeadlineExceeded表示 context 超时，net/http: request canceled可能是 Transport 中断，i/o timeout通常是底层 conn 超时
超时值没有银弹——5s 对 API 是合理，对文件上传就太短；它必须结合下游 SLA、重试策略和用户可接受等待时间一起定。设得太短会增加误失败，太长则拖垮调用方。
