net.DialTimeout 已被弃用，应改用 net.DialContext 配合 context.WithTimeout；它能统一控制 DNS 查询、TCP 连接和 TLS 握手的全链路超时，而 Dialer.Timeout 仅作用于 TCP 阶段且无法取消 DNS 查询。
net.DialTimeout 已被弃用，别再用了
Go 1.8 开始，net.DialTimeout 就标记为已弃用（deprecated），官方明确推荐改用 net.DialContext 配合 context.WithTimeout。直接调用它不仅会触发 go vet 警告，而且在某些场景下行为不一致——比如 DNS 解析超时它管不了，只卡在 TCP 握手阶段。
常见错误现象：net.DialTimeout 返回 timeout: i/o timeout，但实际是 DNS 查询卡住几十秒才失败，根本没走到 TCP 连接这步。
- 必须用
context.Context控制整体生命周期，包括 DNS、TCP 建连、TLS 握手 - 超时时间不是“连接耗时”，而是“从调用开始到成功或彻底失败的总耗时”
- 如果只是想限制 TCP 握手，得靠底层
net.Conn.SetDeadline，但不推荐——太底层、难维护
正确写法：用 DialContext + WithTimeout
这是当前唯一推荐、全链路可控的方式。它能覆盖 DNS 查询、TCP 连接、甚至 TLS 握手（如果你后续用 tls.ClientConn）。
示例：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
conn, err := net.DialContext(ctx, "tcp", "example.com:80", nil)
if err != nil {
// err 可能是 net.OpError，包含 Timeout() 方法可判断
return
}
defer conn.Close()
-
ctx是唯一超时入口，所有子操作（DNS、connect、write）都受其约束 - 不要在
defer cancel()后再用这个ctx—— 它可能已被取消 - 如果连接成功但后续读写要单独设超时，请用
conn.SetReadDeadline/conn.SetWriteDeadline，和 Dial 超时无关
为什么不用 Dialer + Timeout 字段？
有人会翻文档看到 net.Dialer 有 Timeout 和 KeepAlive 字段，以为设了就能替代 context。其实不能。
关键区别：
-
Dialer.Timeout只控制 TCP connect 阶段，对 DNS 查询无效（Go 1.19+ 才在部分平台支持 DNS 超时） -
Dialer.KeepAlive是连接建立后的保活，和建连超时完全无关 -
Dialer没法取消正在进行的 DNS 查询，一旦卡住只能等系统默认超时（常为 30s） -
net.DialContext内部正是用Dialer实现的，但它把上下文传播到了 DNS 层
真实项目里最容易漏掉的一点
很多人写了 context.WithTimeout，但没检查 err 类型，导致超时错误被当成普通网络错误处理。
net.OpError 是常见包装类型，必须用 errors.Is(err, context.DeadlineExceeded) 或 ctx.Err() == context.DeadlineExceeded 来判断是否真超时。
- 直接比较
err.Error()包含 “timeout” 字符串？不可靠，不同系统返回文案不同 - 用
net.OpError.Timeout()方法？它只反映底层 syscall 是否超时，不等于 context 超时 - 最稳妥：先
errors.Is(err, context.DeadlineExceeded)，再 fallback 到errors.Is(err, context.Canceled)
超时控制这件事，看起来就一行 WithTimeout，但真正落地时，DNS、context 生命周期、错误分类，三处都容易出偏差。
