Go HTTP超时不能仅依赖Client.Timeout，必须分层配置：DialContext控制DNS+TCP建连，TLSHandshakeTimeout管控TLS握手，ResponseHeaderTimeout限定响应头接收，Client.Timeout仅作兜底总时限。
Go 的 HTTP 超时不能只靠 Client.Timeout 一把梭——它根本管不住 DNS 查询、TCP 建连卡死、TLS 握手 hang 住这些真实故障点，生产环境一跑就 goroutine 泄漏或请求永久挂起。
http.Client.Timeout 是兜底，不是主力
Client.Timeout 只在 TCP 连接建立完成、TLS 握手成功后才开始计时，覆盖范围是“发完请求 → 读完响应体”这一段。它对以下情况完全无效：
- DNS 解析超时（
net.LookupIP卡住几十秒） - TCP SYN 重传失败（防火墙拦截、目标主机不可达）
- TLS 握手卡在证书验证或 OCSP Stapling 阶段
- 服务端写了部分响应头后崩溃，迟迟不发完整 header
这些阶段出问题时，Client.Timeout 根本没启动，错误类型也不是 context.DeadlineExceeded，而是 *net.OpError 或 *tls.alert，日志里只看到模糊的 i/o timeout 或 connection refused。
必须配 Transport 的 DialContext 和 ResponseHeaderTimeout
真正可控的超时必须下沉到 http.Transport 层，且不能复用 http.DefaultClient —— 它的 Transport 是私有结构，未初始化任何超时值。
立即学习“go语言免费学习笔记（深入）”；
-
DialContext必须用(&net.Dialer{Timeout: 3 * time.Second}).DialContext构造：统一控制 DNS + TCP 全链路建连耗时 -
ResponseHeaderTimeout设为2 * time.Second：限定“请求发出后多久必须收到 status line + headers”，这是防后端已连上但拒绝响应的关键指标 -
TLSHandshakeTimeout显式设为3 * time.Second：HTTPS 场景下必配，避免弱网 TLS 卡死 -
IdleConnTimeout和KeepAlive也要设（如30 * time.Second），否则 NAT 设备静默断连后连接仍被复用
注意：Client.Timeout 应设为略大于各阶段之和（例如 10 * time.Second），仅作安全兜底，而非唯一依赖。
单次请求必须用 context.WithTimeout + http.NewRequestWithContext
硬编码 Client.Timeout 会让所有接口共用一个超时值，无法按业务粒度区分（比如查询用户 2s，支付回调 30s）。正确做法是：
- 每次请求前创建新
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 务必调用
defer cancel()，否则 goroutine 泄漏 - 用
http.NewRequestWithContext(ctx, ...)构造请求，不能只靠req.WithContext(ctx)后再传给client.Do—— 很多 SDK 内部会忽略这个 ctx -
context.DeadlineExceeded错误可直接用errors.Is(err, context.DeadlineExceeded)判断，别用字符串匹配
别碰 SetReadDeadline / SetWriteDeadline，除非你写 TCP 服务端
这两个方法只适用于自定义 TCP 协议服务（如 MQTT broker、RPC server）或需要长连接保活逻辑。HTTP 客户端完全不需要手动调用——http.Transport 已内部封装了读写超时控制。
- 它们是绝对时间点（
time.Time），不是持续时间，每次Read()前都得重设 - 漏设一次就会卡死，且错误类型是
os.ErrDeadlineExceeded，和context.DeadlineExceeded不同源 - HTTP/2 或 gRPC 场景下，底层连接复用机制会让这些 deadline 行为更不可预测
真正容易被忽略的是：即使 context.WithTimeout 和 Transport 都配对了，如果没设 ResponseHeaderTimeout，请求仍可能卡在“已连上但没回 header”状态，而 ctx.Done() 根本不触发——因为底层还没走到可取消的 I/O 阶段。
