net.DialTimeout仅控制TCP连接建立阶段，不适用于HTTP等上层协议；http.Client需显式配置各阶段超时；context.WithTimeout是通用可靠方案，但需底层API支持。
net.DialTimeout 仅控制连接建立阶段
很多人以为 net.DialTimeout 能管住整个请求生命周期，其实它只在 TCP 握手完成前起作用。一旦连接成功（哪怕服务端后续卡死），这个超时就失效了。
常见错误现象：调用 net.DialTimeout 后程序仍长时间阻塞在 conn.Read() 或 conn.Write() 上。
- 适用场景：纯 TCP 连接建立（如自定义协议、长连接池初始化）
- 不适用场景：HTTP 请求、gRPC、数据库连接等上层协议交互
- 注意：
net.DialTimeout已被标记为 deprecated，推荐改用net.Dialer+Context
http.Client 必须显式配置 Timeout 字段
Go 标准库的 http.Client 默认不设任何超时，DefaultClient 的所有字段都是零值 —— 这意味着 DNS 解析、连接建立、TLS 握手、请求发送、响应读取，全部可能无限等待。
正确做法是为每个关键阶段单独设限：
立即学习“go语言免费学习笔记（深入）”；
-
Timeout：总超时（从 Do 开始到响应 Body 关闭），覆盖其他所有超时，优先级最高 -
Transport中设置：DialContext（连接）、TLSHandshakeTimeout（TLS）、ResponseHeaderTimeout（响应头）、IdleConnTimeout（空闲连接） - 示例：
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
ResponseHeaderTimeout: 5 * time.Second,
},
}
context.WithTimeout 是最通用的超时控制手段
对非 HTTP 场景（比如自定义 TCP 协议、gRPC、数据库驱动），context.WithTimeout 是唯一可靠的方式，前提是底层 API 支持 context 参数。
容易踩的坑：
- 没传 context 到 I/O 操作：例如
conn.Read()不接受 context，必须用conn.SetReadDeadline()配合 - gRPC 客户端必须用
ctx传入Invoke或NewClientStream，否则超时无效 - database/sql 的
QueryContext/ExecContext才触发超时，Query/Exec完全忽略
连接池和 Keep-Alive 会干扰超时预期
HTTP 连接复用本身不违反超时逻辑，但 IdleConnTimeout 和 MaxIdleConnsPerHost 设置不当会导致“看似超时失败，实则复用了旧连接”。
典型表现：第一次请求正常，第二次请求突然卡住或返回旧错误。
- 如果服务端主动关闭空闲连接，而客户端未及时感知，下次复用时会触发
read: connection reset by peer -
KeepAlive时间应略小于服务端的 idle timeout（比如服务端设 60s，客户端设 55s） - 高并发下建议限制
MaxIdleConnsPerHost，避免堆积大量待复用连接，拖慢整体超时响应
超时不是加个参数就完事；每个环节的阻塞点都得单独覆盖，而且要区分「连接就绪」和「业务完成」——后者往往需要结合业务逻辑做二次判断。
