go的http.client默认无超时，需手动配置：用dialcontext.timeout控制连接建立（dns+tcp+tls），responseheadertimeout控制响应头接收，整体请求超时用context.withtimeout包裹do()调用。
Go 的 http.Client 默认不设超时，必须手动配
Go 标准库的 http.Client 不会自动设置任何超时——连接卡住、响应迟迟不来、服务端挂了但 TCP 连接还半开着，请求就会一直 hang 住，直到操作系统底层断开（可能几分钟甚至更久）。这不是 bug，是设计选择：把控制权完全交给你。
真正要区分「连接超时」和「读写超时」，得靠 http.Client 的 Transport 字段，而不是直接在 Client 上设一个 Timeout（那个是总超时，覆盖连接+请求+响应全过程，没法拆）。
-
Timeout是「整个请求生命周期」上限，一旦设置，会覆盖掉 Transport 里的部分超时行为，慎用 - 连接建立阶段（DNS + TCP 握手 + TLS）由
Transport.DialContext和TLSClientConfig控制 - 读/写数据阶段（发 request body、收 response header/body）由
Transport.ResponseHeaderTimeout、Transport.ReadTimeout（已弃用）、Transport.WriteTimeout（已弃用）等控制；但 Go 1.12+ 推荐统一用Transport.DialContext+context.WithTimeout管理连接，再配合ResponseHeaderTimeout和IdleConnTimeout
怎么分别设连接超时和读写超时（Go 1.12+ 推荐写法）
核心思路：用自定义 net.Dialer 控制连接建立时间，用 Transport.ResponseHeaderTimeout 控制从发出请求到收到响应头的时间，再用 http.Request 自带的 context 控制整个请求（含 body 读取）的上限。
这样就能做到：连接最多等 5 秒，收到 header 最多再等 10 秒，整个请求（包括读 body）最多 15 秒 —— 三者可独立调节。
client := &http.Client{
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
ResponseHeaderTimeout: 10 * time.Second,
IdleConnTimeout: 30 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
}
<p>// 发起请求时再套一层 context，控制整体生命周期
ctx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
defer cancel()</p><p>req, _ := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39">https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39</a>", nil)
resp, err := client.Do(req)
</p>
-
DialContext.Timeout：只管 DNS 查询 + TCP 连接 + TLS 握手，不包含发送 request 或接收 response -
ResponseHeaderTimeout：从 TCP 连接完成那一刻起，到收到完整 HTTP 响应头为止；如果服务端 header 卡住（比如中间件拦截后没回），它会在此超时 - body 读取超时靠
context：因为resp.Body.Read()是阻塞调用，且不会自动受ResponseHeaderTimeout约束，所以必须用带 timeout 的 context 包裹整个Do()调用
常见错误：混用 Timeout 和 Transport 超时导致行为不可控
如果你同时设置了 http.Client.Timeout 和 Transport 里的各种超时，Go 会按最短的那个生效，而且优先级不透明。尤其 Timeout 会强制取消整个 Do() 流程，可能打断正在读 body 的操作，还掩盖真实瓶颈。
- 现象：
context deadline exceeded错误泛滥，但日志看不出是卡在连接、header 还是 body - 错误写法：
client := &http.Client{Timeout: 10 * time.Second, Transport: transport}，其中 transport 又设了ResponseHeaderTimeout: 3 * time.Second—— 实际表现取决于谁先触发，调试困难 - 建议：禁用
Client.Timeout（设为 0），所有超时逻辑收归Transport+ 请求级context，职责清晰
HTTP/2 下要注意 ResponseHeaderTimeout 不生效
Go 的 http.Transport 在启用 HTTP/2（默认开启）时，ResponseHeaderTimeout 对流式响应（如 server-sent events、长轮询）不起作用，因为它只监控 header 帧到达，而 HTTP/2 允许 header 和 data 帧交错发送。这时候即使 header 已到，后续 data 帧卡住，这个 timeout 也不会触发。
- 现象：HTTP/2 请求返回了 200 OK，但
resp.Body.Read()一直阻塞，ResponseHeaderTimeout毫无反应 - 解法：对需要严格时限的场景（如 API 网关、健康检查），要么降级用 HTTP/1.1（
Transport.ForceAttemptHTTP2 = false），要么在读 body 时自己加time.AfterFunc或用io.LimitReader配合 context 控制单次读操作 - 补充：
TLSHandshakeTimeout和IdleConnTimeout在 HTTP/2 下仍有效，但它们管的是连接层，不是应用层数据流
超时不是设了就完事，关键在分层控制点是否匹配你的协议栈和业务语义。HTTP/2 的帧复用特性会让很多旧经验失效，得盯紧实际数据流路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
