必须显式设置transport.dialcontext.timeout、tlshandshaketimeout和responseheadertimeout三处，否则请求可能卡在dns解析、tcp建连、tls握手或等待响应头阶段；timeout仅控制整体耗时，不覆盖这些前置环节。
http.Client超时配置漏设哪几处？
Go 的 http.Client 超时不是设一个 Timeout 就万事大吉。漏掉任意一环，请求仍可能卡住几十秒才失败。
-
Timeout只覆盖“从发起请求到响应体读完”的总耗时，不包含 DNS 解析、TCP 建连、TLS 握手等前置阶段 -
Transport.DialContext.Timeout控制建连超时（含 DNS 查询），必须显式设置，否则默认无限等待 -
Transport.TLSHandshakeTimeout控制 TLS 握手时限，HTTPS 场景下极易因证书链或中间设备问题卡在此处 -
Transport.ResponseHeaderTimeout决定“发完 request 后多久必须收到 header”，服务端写 header 但卡在 body 生成时，靠它才能及时中断
常见错误现象：http.Get 卡 30 秒才返回 net/http: request canceled (Client.Timeout exceeded while awaiting headers) —— 实际是 ResponseHeaderTimeout 没设，而 Timeout 又太长。
如何定位延迟卡在 DNS / TCP / TLS 哪一环？
用 httptrace 打点比抓包更准，它直接反映 Go runtime 的实际行为，且无需 root 权限。
- 必须通过
req.WithContext(httptrace.WithClientTrace(...))注入 trace，改http.Transport不生效 - 重点关注
DNSStart/DNSDone（DNS 解析慢）、ConnectStart/ConnectDone（TCP 拒绝或 SYN 重传）、TLSStart/TLSDone（握手卡顿） - 若
DNSDone和ConnectStart间隔大，说明本地 DNS 解析慢；若ConnectDone和GOTConn间隔大，大概率是服务端 accept 队列满或连接被中间设备拦截
性能影响极小，临时开启 DEBUG 日志即可，适合生产环境紧急排查。
net.Conn.Read 卡住却不报错？检查这三件事
根本原因不是 Go 阻塞，而是底层 socket 没数据、没关闭、也没超时——它就在那儿一直等。
- 确认是否调用了
conn.SetReadDeadline：HTTP 客户端自动处理，但自定义 TCP 连接或bufio.Reader场景下极易遗漏 - 注意
bufio.Reader缓冲机制：它会先填满内部 buffer 才触发底层Read，看起来“卡住”实则是没攒够数据，需用Peek或ReadString配合 deadline - 对端
close()后，Linux TCP 栈可能延迟发送 FIN，导致Read等数秒才返回io.EOF，这不是 bug，是协议栈行为
别用 select + time.After 替代 SetReadDeadline：前者无法取消系统调用，goroutine 放弃等待了，但内核里的 read() 仍在阻塞。
pprof 和 httptrace 都没发现瓶颈？查连接池和上下文传递
高延迟常来自资源层而非代码逻辑本身，尤其是连接复用和上下文传播被忽略时。
-
http.Transport.MaxIdleConns和MaxIdleConnsPerHost过小，会导致频繁建连；过大则可能耗尽文件描述符，表现为too many open files - 下游服务（如数据库、Redis）未设 context 超时，上游 HTTP 请求已超时，但 goroutine 仍在等 DB 返回，造成堆积
- HTTP handler 中启动 goroutine 但没传入 request context，导致超时后 goroutine 无法 cancel，持续占用资源
真正难排查的，往往不是某段代码慢，而是“本该结束的请求，还在后台偷偷跑着”。检查所有 go func() 是否接收并使用了 ctx，所有 db.QueryContext、redis.Do 是否绑定了超时 context。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
