http client 必须显式设置超时，推荐优先使用 client.timeout 或 context.withtimeout；前者控制总耗时，后者支持细粒度控制与主动取消；避免误用 transport 层各 timeout 字段。
HTTP Client 默认不超时，必须显式设置
Go 的 http.Client 默认没有超时限制，一旦后端卡住、网络断开或 DNS 慢，Do() 会一直挂起，直到 TCP 层最终断连（可能长达几分钟）。这不是 bug，是设计选择——但生产环境绝对不能依赖它。
正确做法是为整个请求生命周期设上限：连接、读、写都得管。最常用也最安全的是用 Timeout 字段，它等效于同时设置 ConnectTimeout 和 ReadTimeout（注意：不控制 WriteTimeout，但对普通 GET/POST 已足够）。
-
Timeout是总耗时上限，从Do()开始计时，包含 DNS 解析、建连、TLS 握手、发送请求、读响应头+体 - 若只需控制建连阶段，用
Transport.DialContext配合net.Dialer.Timeout - 不要只设
ReadTimeout：它只管读响应体，不防 DNS 卡死或 SYN 包丢弃
client := &http.Client{
Timeout: 5 * time.Second,
}
用 context.WithTimeout 精确控制单次请求
当需要更细粒度控制（比如不同接口超时不同），或者想在超时后主动取消请求（避免 goroutine 泄漏），就得用 context。这是 Go 1.7+ 推荐方式，比单纯设 Timeout 更灵活可靠。
关键点：必须把 context 传给 http.Request，而不是只传给 Client.Do()；否则超时不会中断底层连接。
- 调用
http.NewRequestWithContext(ctx, ...)构造带上下文的请求 - 直接传原生
*http.Request给client.Do()，不要用client.Get()这类快捷方法（它们不支持 context） - 超时触发后，
ctx.Err()会是context.DeadlineExceeded，可据此区分错误类型
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>req, _ := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>", nil)
resp, err := client.Do(req)
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
// 真正的超时
}
}</p>
Transport 层超时参数容易混淆
http.Transport 有多个 timeout 字段，名字相近但作用完全不同，混用会导致预期外行为：
-
IdleConnTimeout：空闲连接保活时间，影响复用，和单次请求超时不相关 -
TLSHandshakeTimeout：仅限 TLS 握手阶段，不覆盖 DNS 或 TCP 建连 -
ExpectContinueTimeout：极少见，仅用于100-continue场景 -
ResponseHeaderTimeout：从发完请求到收到响应头的上限，适合防“服务端已收请求但迟迟不返回 header”的情况
除非明确要隔离某阶段（比如你发现 header 总是慢但 body 快），否则优先用 Client.Timeout 或 context。乱配 Transport 超时反而会让逻辑更难推理。
测试超时是否真正生效的简单方法
本地验证超时逻辑是否起作用，别只靠日志或猜测。最直接的方式是启动一个故意 sleep 的 HTTP 服务，然后用你的 client 调用它：
- 用
net/http/httptest启一个 handler，time.Sleep(10 * time.Second) - 用你配置好的
http.Client去请求它 - 检查返回的
err是否非 nil，且errors.Is(err, context.DeadlineExceeded)或包含"timeout"字样 - 注意：如果用
curl -v测试，看到Connection timed out是系统级超时，不是 Go 应用层的
真实环境里，DNS 解析失败、SYN 包被丢、中间代理静默丢包，这些都会让超时表现不一致。所以别只测 “sleep”，还得压测弱网场景。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
