Java 11 HttpClient 的 connectTimeout 仅控制 TCP 连接建立阶段超时，不涵盖 DNS 解析、请求发送或响应接收；需通过 HttpClient.newBuilder().connectTimeout(Duration) 设置，超时触发 HttpConnectTimeoutException。
http.Client.Timeout 不是超时控制函数，它只是个字段；真正能“控制”超时的函数只有 context.WithTimeout 和 http.NewRequestWithContext。只设 Timeout 会漏掉 DNS、TLS、连接建立等阶段，且无法被外部取消。
为什么 Client.Timeout 常常不生效
它只在请求全程（DNS → connect → TLS → write → read headers → read body）结束后才检查总耗时，中间任何环节卡住都不会提前中断。比如 DNS 解析慢、服务端迟迟不发 header、body 流式返回但卡在中间，Timeout 都不会触发——它不是“阶段超时”，而是“事后计时器”。
- 常见错误现象：
net/http: request canceled (Client.Timeout exceeded while awaiting headers)—— 实际是 transport 层的ResponseHeaderTimeout先触发了，和Client.Timeout无关 -
Client.Timeout默认为 0，即无限等待；设了也不影响 transport 内部各阶段 timeout 的优先级判断 - 若同时设置了
Client.Timeout和context.WithTimeout，两者可能冲突：一个想 5 秒停，另一个底层 transport 在 3 秒就报错，错误类型还不一致
必须用 context.WithTimeout + WithRequestContext
这是唯一能穿透 DNS、connect、TLS、write、read 全链路的方案，前提是正确传入 context。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 构造请求必须用
http.NewRequestWithContext(ctx, ...)或显式调用req.WithContext(ctx)，否则ctx对Do()完全无效 - 必须配对调用
cancel()，推荐defer cancel()，但要在所有return分支前确保执行（尤其 error 处理路径） - 错误判断要用
errors.Is(err, context.DeadlineExceeded)，不要字符串匹配"timeout"—— 不同 transport 下错误信息格式不一致 - 示例：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() req, _ := http.NewRequestWithContext(ctx, "GET", "https://api.example.com", nil) resp, err := client.Do(req)
http.Transport 的 timeout 字段不能省
context 虽然能发信号，但某些系统调用（尤其是 Windows 或旧版 Go 的 DNS 解析）不响应取消。这时需要 transport 层兜底：
立即学习“go语言免费学习笔记（深入）”；
-
DialContextTimeout：控制 TCP 连接建立（含 DNS），建议设为3–5s，比 context 总超时短 -
TLSHandshakeTimeout：仅 HTTPS 有效，建议3s，防握手卡死 -
ResponseHeaderTimeout：从连接完成到收到 status line + headers 的上限，建议2–4s，这是防“假连接”的关键 - 注意：
ResponseHeaderTimeout对 body 读取完全无效；body 超时必须靠ctx或手动io.ReadFull(..., ctx.Done())
容易被忽略的三个细节
第一，Client.Timeout 应设为 0，避免和 context 冲突；第二，同一个 ctx 不能复用于多个独立请求，否则一个超时会 cancel 掉全部；第三，如果用了自定义 http.Transport，它的 IdleConnTimeout 和 MaxIdleConnsPerHost 会影响连接复用行为，间接拖慢超时判定——高并发下这点特别明显。
