net.dialtimeout 已被弃用，应改用 net.dialcontext 配合 context.withtimeout；它统一控制 dns 查询、tcp 连接和 tls 握手全链路超时，而 dialer.timeout 仅作用于 tcp 阶段且无法取消 dns 查询。
net.DialTimeout 已被弃用，别再用了。Go 1.17 起官方明确标记为 deprecated，govet 会警告，且行为不可靠——它只管 TCP 握手，完全不控制 DNS 解析超时，实际卡住时你看到的 "i/o timeout" 很可能来自 30 秒 DNS 查询失败，根本没走到 connect 阶段。
net.DialContext 是当前唯一推荐的建连超时方式
net.DialContext 把超时控制下沉到整个拨号链路：DNS 查询 → TCP 连接 →（可选）TLS 握手（若后续封装），且支持随时取消。
- 错误类型统一为
*net.OpError，可用errors.Is(err, context.DeadlineExceeded)或netErr.Timeout()判断 -
ctx必须在defer cancel()前创建，且不能复用已取消的 ctx - 不要和
net.Dialer.Timeout混用；DialContext内部已用Dialer实现，但多了上下文传播能力
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
conn, err := net.DialContext(ctx, "tcp", "example.com:80")
if err != nil {
if errors.Is(err, context.DeadlineExceeded) {
log.Println("DNS 或 TCP 建连超时")
}
return
}
defer conn.Close()
net.Dialer.Timeout 仅适用于纯 TCP 握手阶段控制
如果你确定不需要 DNS 超时（比如直连 IP），或项目受限于旧版 Go（*net.Dialer。
-
Timeout字段只作用于内核connect()系统调用，从 SYN 发出到 ACK+SYN 返回完成 - 必须配
KeepAlive: 30 * time.Second，否则 NAT 或中间设备静默断连后连接仍显示“活跃” -
net.Dialer不处理 TLS，HTTPS 场景下必须配合tls.Client单独设TLSHandshakeTimeout
dialer := &net.Dialer{
Timeout: 4 * time.Second,
KeepAlive: 30 * time.Second,
}
conn, err := dialer.Dial("tcp", "192.168.1.100:8080")
SetReadDeadline 和 SetWriteDeadline 必须每次 I/O 前重设
建连成功 ≠ 安全。读写阶段超时和建连超时完全独立，漏掉任一环节都可能卡死几分钟。
-
deadline是time.Time绝对时间点，不是持续时间；传入过去时间会立刻返回os.ErrDeadlineExceeded - 每次
conn.Read()前必须调conn.SetReadDeadline(time.Now().Add(3 * time.Second)) - 同理，每次
conn.Write()前也得设SetWriteDeadline；不要用SetDeadline替代，读写超时需求通常不同 -
bufio.Reader会缓存底层Read()，必须在每次reader.Read()调用前手动重设 conn 的 deadline
最易忽略的是：超时后连接不会自动关闭，需自行 conn.Close()，否则 fd 泄露、goroutine 持有连接不释放。
复杂点不在语法，而在于阶段割裂：DNS、TCP、TLS、Header、Body、空闲……每个环节都要单独设限，且错误类型不统一。生产环境里，一个 context.WithTimeout + 自定义 http.Transport 才是 HTTP 请求的真实控制器；裸 net.Conn 场景则必须三段全控——DialContext、ReadDeadline、WriteDeadline，缺一不可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
