Go模块网络IO瓶颈需通过httptrace日志定位卡点，而非抓包；DNSStart/DNSDone、ConnectStart/ConnectDone、GotConn等字段可精准识别DNS慢、建连失败或连接复用失效问题；必须显式配置DialContext.Timeout、TLSHandshakeTimeout和ResponseHeaderTimeout，避免超时相互掩盖。
Go 模块的网络 IO 瓶颈通常不是“连不上”，而是卡在 DNS、建连、TLS、首字节响应或连接复用失效上——直接看 http.Client 超时配置和 httptrace 日志，比抓包更快定位真实卡点。
用 httptrace 看清 HTTP 请求卡在哪一环
很多“慢请求”实际是 DNS 解析耗时 2 秒、TCP 连接被拒绝后重试 3 次、或 TLS 握手超时导致整体延迟飙升。标准库 httptrace 能打点到每个子阶段，不依赖外部工具。
- 必须通过
req.WithContext(httptrace.WithClientTrace())注入 trace，改Transport不生效 - 重点关注
DNSStart/DNSDone（判断是否 DNS 污染或解析慢）、ConnectStart/ConnectDone（确认是否服务端端口未开或防火墙拦截）、GotConn（看Reused是否为false，排查连接复用失效） - 日志里出现大量
ConnectDone: error=dial tcp x.x.x.x:443: i/o timeout，说明建连失败，不是业务逻辑问题
检查 http.Client 的三重超时是否漏配
Timeout 字段只是兜底项，它不覆盖 DNS、TLS、Header 等中间环节。没配全会导致请求卡在某个阶段不动，但错误信息却显示为 “context deadline exceeded” —— 实际根本没走到业务层。
-
DialContext.Timeout控制建连耗时（含 DNS），建议设为 3–5s -
TLSHandshakeTimeout必须显式设置（默认 0，即无限等待），尤其在使用自签名证书或弱网环境 -
ResponseHeaderTimeout决定从发完 request 到收到 status line 的最大等待时间；若服务端只写 header 不写 body，不设此项就会卡死 - 别用
http.DefaultClient，它的所有超时字段都是 0
验证连接复用是否真正生效
即使开了 keep-alive，连接也可能因配置不当无法复用，导致每请求都新建 TCP 连接，放大 DNS 和 TLS 开销。
立即学习“go语言免费学习笔记（深入）”；
-
MaxIdleConns和MaxIdleConnsPerHost都不能为 0 或过小（如设成 1），否则连接池形同虚设 -
IdleConnTimeout要小于后端服务的keepalive_timeout（例如 Nginx 默认 75s，客户端设 30s 就可能提前断连） - trace 中持续看到
GotConn: reused=false，且WasIdle=false，说明连接刚建好就被关了，不是复用问题而是服务端主动断连
区分是网络层阻塞还是业务层阻塞
响应慢 ≠ 网络慢。goroutine 卡在 chan receive 或 semacquire 是锁或 channel 阻塞，不是网络问题；而卡在 net.Conn.Read 或 select 等待 socket 事件，才是真网络阻塞。
- 访问
http://localhost:6060/debug/pprof/goroutine?debug=2，搜索read、write、dial等关键词，确认 goroutine 是否停在系统调用上 - 如果大量 goroutine 停在
runtime.gopark+net.(*pollDesc).waitRead，说明 socket 没数据且没设SetReadDeadline - 若停在
database/sql.(*DB).conn或redis.(*Conn).Read，问题在下游依赖，不是本模块网络 IO
真正难搞的不是超时参数本身，而是不同环节的超时相互掩盖：比如 ResponseHeaderTimeout 没设，Timeout 又设得太长，结果你看到的是“10 秒超时”，但实际前 9 秒都在等 TLS 握手失败重试——这种嵌套延迟必须靠 httptrace 拆开看。
