Go 的 http.Client 默认无超时，生产环境必须显式配置：Client.Timeout 作总超时兜底，Transport 分阶段控制各网络环节，context.WithTimeout 实现请求级动态取消。
Go 的 http.Client 默认**没有超时**，直接用 http.Get() 或 http.DefaultClient 在生产环境极易卡死——DNS 解析慢、目标不可达、TLS 握手卡住，都可能让 goroutine 无限等待。必须显式配置超时，而且不能只设一个 Timeout 就完事。
用 Client.Timeout 做兜底，但别指望它解决所有问题
这是最简单也最常用的起点，控制从 Do() 开始到响应体读完的**总耗时**：
client := &http.Client{
Timeout: 10 * time.Second,
}
resp, err := client.Get("https://www./link/710ba53b0d353329706ee1bedf4b9b39")
但它会粗暴取消整个请求（含底层连接），无法区分是连不上、卡在握手，还是服务端迟迟不发响应头。所以它适合做“最后保险”，值建议设为略大于预期最大耗时（如 8–15 秒），且必须大于 Transport 各阶段超时之和。
- 若设太小（比如 2 秒），可能在 DNS 查询或 TCP 连接阶段就超时，掩盖真实瓶颈
- 若完全不设，
err可能是*url.Error，其Timeout()方法返回true，可据此判断是否超时 - 注意：它不控制连接池空闲时间，
IdleConnTimeout是 Transport 的独立配置
用 http.Transport 分阶段控制，防卡死在具体环节
真正稳定的服务调用，得靠 Transport 精细管理各网络阶段。常见组合如下：
transport := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second, // TCP 连接建立
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second, // HTTPS 握手
ResponseHeaderTimeout: 3 * time.Second, // 发出请求后，等响应头返回的时间
IdleConnTimeout: 60 * time.Second, // 连接池中空闲连接存活时间
MaxIdleConns: 100,
MaxIdleConnsPerHost: 10,
}
client := &http.Client{
Transport: transport,
Timeout: 15 * time.Second, // 总超时仍需兜底
}
ResponseHeaderTimeout 尤其关键——它能快速拦截那种“连得上但服务器 hang 住不发 HTTP/1.1 200 OK”的场景，避免浪费整体超时预算。
-
DialContext.Timeout和TLSHandshakeTimeout应小于ResponseHeaderTimeout，否则前者没机会触发 -
IdleConnTimeout影响连接复用效率，设太短（如 5 秒）会导致频繁重连；太长（如 5 分钟）可能积压无效连接 - Go 1.19+ 已弃用
KeepAlive的旧写法，统一用DialContext配置
用 context.WithTimeout 实现请求级动态取消
当需要对单个请求单独控制生命周期（比如用户操作中途取消、上游限流提前终止），context 是唯一可靠方式：
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second) defer cancel()req, _ := http.NewRequestWithContext(ctx, "GET", "https://www./link/710ba53b0d353329706ee1bedf4b9b39", nil) resp, err := client.Do(req) // 注意：这里 client 不必设 Timeout，由 ctx 主导
它比 Client.Timeout 更灵活：可随时 cancel()，可跨 goroutine 传递，还能结合 context.WithCancel 或 context.WithDeadline。但要注意：client.Timeout 和 context 超时同时存在时，**任一触发即取消请求**，二者是“或”关系，不是叠加。
- 如果
client.Timeout设了 10 秒，context设了 3 秒，那实际就是 3 秒超时 -
req.Context().Err()在超时后会返回context.DeadlineExceeded，比判断net.Error.Timeout()更准确 - 不要在
defer cancel()后再用该ctx发起其他请求，否则会被误关
真正的难点不在“怎么设”，而在“设多少”。DNS、TCP、TLS、服务端处理、网络抖动——每个环节都可能拖慢请求。建议先用 ResponseHeaderTimeout 和 DialContext.Timeout 快速暴露瓶颈，再根据监控数据反推合理值。别迷信“统一设 5 秒”，内网调用和跨境 API 的超时策略天差地别。
