Go 中设置 TCP 连接超时最直接有效的方式是使用 net.Dialer 并配置 Timeout 字段，它控制 connect() 到三次握手完成的建立阶段，而非读写；默认 net.Dial 无超时，需显式构造 *net.Dialer，推荐设为 3–5 秒。
Go 中设置 TCP 连接超时，最直接有效的方式是使用 net.Dialer 并配置其 Timeout 字段——它控制的是从发起 connect() 到完成三次握手的整个过程，而非后续读写。
用 net.Dialer.Timeout 控制连接建立阶段超时
这是解决“客户端卡在 Dial 不返回”的核心手段。默认 net.Dial 没有超时，可能阻塞数分钟（取决于系统 tcp_syn_retries 和路由状况）。
- 必须显式构造
*net.Dialer，不能只靠net.Dial("tcp", ...) -
Timeout是绝对耗时上限，单位是time.Duration，推荐设为3–5 * time.Second - 若超时，错误类型为
*net.OpError，且err.Timeout()为true - 注意：该超时仅作用于连接建立，不影响后续
Read/Write行为
package mainimport ( "fmt" "net" "time" )
func main() { dialer := &net.Dialer{ Timeout: 4 time.Second, KeepAlive: 30 time.Second, } conn, err := dialer.Dial("tcp", "192.168.0.1:8080") if err != nil { if netErr, ok := err.(net.Error); ok && netErr.Timeout() { fmt.Println("连接超时：目标不可达或网络异常") } else { fmt.Printf("其他连接错误：%v\n", err) } return } defer conn.Close() fmt.Println("连接成功") }
为什么不能只靠 conn.SetReadDeadline？
SetReadDeadline 只对已建立连接后的 Read 操作生效，对 Dial 阶段完全无效。很多开发者误以为设了它就能防住“连不上”，结果发现程序仍卡死在 Dial 上。
-
SetReadDeadline(time.Now().Add(5 * time.Second))必须在conn.Read()前调用，且每次Read前都得重设（否则第二次读会立即超时） - 它解决的是“连上了但对方不发数据”的问题，不是“连都连不上”
- 常见误用：
conn.SetReadDeadline(time.Now())—— 这等于立刻超时，毫无意义
HTTP 客户端场景下，别只设 Client.Timeout
如果你用的是 http.Client，光设 Timeout 虽能兜底，但无法区分是卡在 DNS、连接、TLS 还是响应头阶段。这会让排障变困难，也影响重试策略。
-
Client.Timeout是总开关，覆盖整个请求生命周期（含连接、写请求、读响应头、读响应体） - 真正需要细粒度控制时，必须自定义
http.Transport，重点配DialContext（底层就是net.Dialer）和ResponseHeaderTimeout - 例如：DNS 解析慢 ≠ 连接慢 ≠ 服务端处理慢，混在一起超时会掩盖真实瓶颈
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second, // 单独控制连接超时
KeepAlive: 30 * time.Second,
}).DialContext,
ResponseHeaderTimeout: 2 * time.Second, // 等响应头不能太久
IdleConnTimeout: 60 * time.Second,
},
}真正容易被忽略的点是：TCP 连接超时和应用层读写超时是两套独立机制，必须按阶段分别设置；而多数线上故障，恰恰卡在“连不上”这个最基础环节——所以 net.Dialer.Timeout 不是可选项，是必选项。
