Go语言TCP连接超时必须分阶段控制：建连用net.Dialer.Timeout（3–5秒），读写用SetRead/WriteDeadline（每次调用前重算），HTTP客户端应禁用Client.Timeout而改用context.WithTimeout配合Transport精细配置。
Go 语言连接超时不能只设一次就完事，必须分阶段控制：建连（Dial）、读（Read）、写（Write）三者超时互不影响，漏掉任意一环都可能卡住几十秒甚至几分钟。
net.Dialer.Timeout 控制 TCP 建连全过程
这是解决“程序卡在 Dial 不返回”的唯一有效手段。默认 net.Dial 完全无超时，底层会等系统级 SYN 重传结束（Linux 默认最多 3 分钟）。net.DialTimeout 已被标记为 deprecated，必须用 *net.Dialer。
-
Timeout字段控制从 DNS 解析开始、到三次握手完成的总耗时，推荐设为3 * time.Second到5 * time.Second -
KeepAlive需显式设置（如30 * time.Second），否则连接断开后仍显示“活跃”，直到下次读写才暴露问题 - 错误类型是
*net.OpError，判断方式：err != nil && netErr, ok := err.(net.Error); ok && netErr.Timeout()
conn.SetReadDeadline 必须每次读前重算
它只对已建立的连接生效，和 Dial 阶段完全无关。常见错误是把一个固定时间点（比如初始化时算好的 time.Now().Add(10 * time.Second)）反复传给 SetReadDeadline，导致第二次 Read 立即返回 i/o timeout。
- 每次调用
Read前，必须重新调用conn.SetReadDeadline(time.Now().Add(5 * time.Second)) - 超时后连接不会自动关闭，需手动处理；错误类型仍是
net.Error，用netErr.Timeout()判断 - 若要实现“空闲超时”（即连续 N 秒没数据才断开），就必须在每次读前更新 deadline；固定时间戳等于自废武功
HTTP 客户端别只靠 Client.Timeout
http.Client.Timeout 是个兜底总开关，但它会覆盖 Transport 层所有精细配置，且无法定位卡点在哪——DNS？TLS？还是服务端发了 header 就不发 body？生产环境应禁用它（设为 0），改用 context.WithTimeout + 自定义 http.Transport。
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout构造请求上下文，并通过http.NewRequestWithContext注入，这才是请求生命周期的真实控制器 -
http.Transport中重点配三个字段：DialContext（含*net.Dialer{Timeout: 3 * time.Second}）、TLSHandshakeTimeout（HTTPS 必设，建议 3–5 秒）、ResponseHeaderTimeout（防服务端“半开”，3–5 秒合理） - 务必关闭
resp.Body，否则连接无法归还连接池，MaxIdleConnsPerHost很快打满
最易被忽略的是：超时错误类型不统一，context.DeadlineExceeded 和底层 net.OpError 必须用 errors.Is 或类型断言区分，字符串匹配在 Go 1.20+ 后极不可靠。
