HTTP客户端超时必须显式设置，Go默认无限制；推荐用http.Client.Timeout控制总耗时，但注意不包含重定向耗时，或自定义Transport精细控制各阶段超时。
HTTP客户端超时必须显式设置，Go默认不设限
Go 的 http.Client 默认没有超时控制，req.Context() 未传入时，一次卡死的 DNS 解析或服务无响应可能让整个 goroutine 永久阻塞。这不是 bug，是设计选择——但生产环境几乎从不接受它。
最简可控方式是直接配置 http.Client 的三个字段：
-
Timeout：总超时，覆盖连接、TLS 握手、写请求、读响应全过程（推荐初用） -
Transport下的DialContext+tls.Config：精细控制各阶段（如单独设 DNS 超时） - 不建议只靠
context.WithTimeout()包裹单次Do()，它无法中断底层 TCP 连接建立
用 Timeout 字段最安全，但注意它不包含重定向耗时
Timeout 从 Do() 开始计时，到收到完整响应体结束；但如果启用了重定向（默认开启），中间每次 302 的请求-响应循环都各自计入该超时。也就是说，若设 Timeout: 5 * time.Second，而服务端连续跳转 3 次，每次耗时 2s，第三次就会直接超时失败。
解决办法只有两个：
立即学习“go语言免费学习笔记（深入）”；
- 关闭自动重定向：
CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse } - 改用
Transport级超时（见下一条），再手动处理重定向逻辑
Transport 超时参数多，但 DialContext 和 TLSHandshakeTimeout 最常被漏掉
当需要区分连接建立、TLS 握手、响应读取等阶段超时时，必须自定义 http.Transport。常见错误是只设了 ResponseHeaderTimeout，结果 DNS 卡住 30 秒才报错。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键字段及典型值：
-
DialContext：控制 DNS 查询 + TCP 连接，建议设5 * time.Second -
TLSHandshakeTimeout：仅 TLS 握手，设10 * time.Second防止老旧服务慢握手拖累 -
ResponseHeaderTimeout：从发完请求到收到 status line 的时间，设5 * time.Second -
IdleConnTimeout：空闲连接保活时间，和超时无关，别误当超时用
示例片段：
tr := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 10 * time.Second,
ResponseHeaderTimeout: 5 * time.Second,
}HTTP 服务端超时容易混淆 ReadTimeout 和 ReadHeaderTimeout
服务端用 http.Server 时，ReadTimeout 是从连接建立开始计时，包括 TLS 握手、请求头、请求体全部读完；而 ReadHeaderTimeout 只管请求头（即第一行 + 所有 header 行）的读取时间。
实际影响：
- 大文件上传场景，
ReadTimeout设太短会直接中断上传；应优先调大它，或改用流式处理 + context 控制 -
ReadHeaderTimeout必须小于ReadTimeout，否则无效；建议设为5 * time.Second防恶意客户端慢速发 header -
WriteTimeout控制响应写出耗时，但不包含 response body 写入后的连接保持时间
这些字段在 Go 1.8+ 后仍有效，但新项目更推荐用 http.TimeoutHandler 包裹 handler，它基于 context 实现，对长连接更友好。
超时不是越短越好，每个环节的真实延迟分布得看监控数据；盲目统一设 1s，可能把正常的数据库慢查询或外部 API 延迟也干掉了。
