Go HTTP Client 超时：别让默认客户端拖住 goroutine

Go 的 http.DefaultClient 没有总超时。对内部工具脚本影响不大，但在服务端代码里非常危险：下游卡住时，请求 goroutine、连接和内存都会持续占用。

Client.Timeout 是总预算

Client.Timeout 覆盖从发起请求到读取响应体的总时间。它简单直接，适合大多数普通调用，但也要和入口 context 的 deadline 保持一致。

Transport 管连接细节

DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout 和 IdleConnTimeout 分别控制建连、TLS 握手、响应头等待和空闲连接生命周期。它们能帮助你定位到底慢在哪里。

读取响应体也要受控

只设置请求发出前的超时不够，读取 body 同样可能慢。请求结束后必须关闭 body，否则连接无法复用。

生产场景

适用于调用支付、搜索、推荐、文件服务和第三方 API 的服务端代码。默认客户端没有总超时，线上风险主要出现在下游卡住但连接不释放。

关键指标

• 建连、TLS、响应头等待和读取 body 的耗时
• 下游超时错误按目标服务拆分
• 正在等待响应的 goroutine 与连接数

常见误区

• 直接使用 http.DefaultClient
• 只设置 Transport 超时，不设置总预算或入口 context
• 忘记关闭 body 导致连接池不可复用

落地建议

建议为每个重要下游封装专用 client，并把 timeout、重试、日志、trace 和指标集中在这一层。响应体即使不读取内容，也要正确 Close。

代码示例

client := &http.Client{
    Timeout: 800 * time.Millisecond,
    Transport: &http.Transport{
        DialContext: (&net.Dialer{Timeout: 150 * time.Millisecond}).DialContext,
        ResponseHeaderTimeout: 300 * time.Millisecond,
        IdleConnTimeout: 90 * time.Second,
    },
}

上线检查

• 禁止在服务端使用无超时 DefaultClient。
• 响应体始终 defer Close。
• 下游超时指标按目标服务拆分。