Go网络超时需分层控制：用context.WithTimeout管理请求生命周期，http.Transport细化DNS、TLS、响应头等各阶段超时，错误判断须用errors.Is(err, context.DeadlineExceeded)或net.Error.Timeout()。
Go 设置网络超时不能只靠一个 Timeout 字段糊弄过去——它容易掩盖问题、覆盖 context 行为，还可能在高并发下引发连接堆积或 goroutine 泄漏。真正稳的方案是分层控制：用 context 管生命周期，用 http.Transport 管连接细节，错误处理再精准识别超时类型。
用 context.WithTimeout 控制请求整体生命周期
这是最推荐、也最符合 Go 云原生实践的方式。它不只管“耗时”，还支持主动取消、链路传递和重试集成。
- 创建带超时的
context：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 务必在请求结束后调用
cancel()（哪怕提前成功），否则会泄漏 goroutine - 把
ctx注入请求：req := http.NewRequestWithContext(ctx, "GET", url, nil)，后续client.Do(req)全程受控 - 超时后底层 TCP 连接会被关闭，返回的错误是
context.DeadlineExceeded，不是字符串匹配能判断的
用 http.Transport 细化各阶段超时
仅靠 context 无法限制 DNS 解析慢、TLS 握手卡住、响应头迟迟不来等具体环节。这时必须配置 Transport。
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
-
DialContext：控制 DNS + TCP 建连总耗时，建议设为3–5s；用(&net.Dialer{Timeout: 3 * time.Second}).DialContext -
TLSHandshakeTimeout：HTTPS 必设，尤其对接老服务或弱网环境，3–5s较稳妥 -
ResponseHeaderTimeout：从发出请求到收到状态行和 headers 的最大等待时间，防服务“已连上但不发头”，3–5s合理 -
IdleConnTimeout和KeepAlive：避免空闲连接长期占着不放，影响连接复用效率 - 禁用
client.Timeout（设为0）：Go 1.19+ 已标记为 legacy，它和 context 冲突且语义模糊
如何正确判断是不是超时错误
很多同学用 err.Error() == "timeout" 或 strings.Contains(err.Error(), "timeout")，这在不同 Go 版本或不同底层协议（HTTP/2、gRPC）下极易失效。
- 判断 context 超时：
errors.Is(err, context.DeadlineExceeded) - 判断底层 I/O 超时（如 Dial、Read、Write）：
ne, ok := err.(net.Error); ok && ne.Timeout() - 不要依赖
*url.Error的Err字段做字符串比对——它可能是net.OpError、tls.alert或其他包装类型
别碰 SetReadDeadline / SetWriteDeadline 的常见场景
除非你在写自定义 TCP 协议服务（比如 MQTT broker、RPC server）、或需要长连接保活逻辑，否则几乎不需要手动调用这两个方法。
- 它们设置的是**绝对时间点**，不是相对超时；每次
Read或Write前都得重设，漏一次就永久卡死 - HTTP 客户端完全由
http.Transport内部管理 deadline，手动干预反而破坏复用逻辑 - 想快速建连？用
net.DialTimeout；想控读响应体？用context+io.CopyN或流式处理时定期检查ctx.Err()
真正难的不是写对那几行超时代码，而是理解每个参数生效的位置和失效的边界——比如 ResponseHeaderTimeout 不管响应体读取，context 超时会中断正在读 body 的流，而 IdleConnTimeout 只影响连接池里的空闲连接。这些细节不厘清，线上一出问题，就只能靠猜。
