最可靠方式是用 net.Dialer.Timeout 控制 TCP 连接建立超时；它覆盖 DNS 解析和三次握手，不适用于读写；HTTP 客户端需通过 Transport.DialContext 和 TLSHandshakeTimeout 分别配置连接与 TLS 超时。
Go 中设置 TCP 连接超时，最可靠、最常用的方式是用 net.Dialer 配置 Timeout 字段；直接调用 net.Dial 会继承默认无超时行为，极易卡死。
用 net.Dialer 控制连接建立阶段超时
这是 Go 官方推荐的现代做法，适用于所有基于 net.Conn 的底层通信（如自定义协议、gRPC 底层连接、Redis 客户端等）。
-
net.Dialer.Timeout只控制“从开始拨号到完成 TCP 三次握手”的耗时，不涉及后续读写 - 它比老式
net.Dial+SetDeadline更清晰、更安全，不会因忘记重设 deadline 导致阻塞 - 若目标地址 DNS 解析慢，
Dialer.Timeout也覆盖解析阶段（Go 1.19+ 默认使用纯 Go DNS 解析器）
dia := &net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}
conn, err := dia.Dial("tcp", "api.example.com:443")
if err != nil {
// err 可能是 net.OpError，且 e.Timeout() == true
log.Printf("connect timeout or failed: %v", err)
return
}
defer conn.Close()别误用 SetDeadline 来替代连接超时
conn.SetDeadline 是对已建立连接的读/写操作设限，不能解决“连不上”的问题 —— 它在 Dial 返回后才生效，而 Dial 本身可能卡住几十秒。
- 常见错误：先
net.Dial，再SetDeadline，结果连接阶段就 hang 住 -
SetReadDeadline和SetWriteDeadline必须每次读/写前重新设置，否则只影响下一次 I/O - 仅适合服务端长连接场景（如 HTTP Server 处理单个请求时限制客户端发包节奏）
HTTP 客户端里，连接超时由 Transport 控制
如果你用的是 http.Client，不要试图在 Client.Timeout 里塞一个“够短”的值来代替连接超时 —— 它是总耗时上限，无法单独约束连接阶段。
立即学习“go语言免费学习笔记（深入）”；
- 真正管连接建立的是
http.Transport.DialContext，必须通过net.Dialer注入 - 漏配
DialContext会导致即使设置了Client.Timeout = 5s，遇到 DNS 故障或防火墙拦截时仍可能卡满 30 秒（Go 默认net.Dial超时） - HTTPS 场景还需额外配
TLSHandshakeTimeout，否则 TLS 握手失败也会拖慢整体响应
tr := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 2 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 2 * time.Second,
}
client := &http.Client{Transport: tr, Timeout: 8 * time.Second}最容易被忽略的一点：没有显式配置 DialContext 的 http.Transport，其连接行为完全依赖 Go 运行时默认策略，不同版本表现可能不一致；生产环境务必显式声明。
