pprof 不能抓网络延迟，但能通过 goroutine 分析排除干扰项；真实网络耗时需用 tcpdump 验证，超时配置须分层（DialContext、TLS、ResponseHeader 等），跨机房需隔离连接池与 tracer。
pprof 能抓到网络延迟吗？不能，但能帮你排除干扰项
pprof 本身不记录网络等待时间，net.Conn.Read 或 http.Transport.RoundTrip 卡住时，CPU profile 里看不到耗时——goroutine 处于 select 或 syscall.Syscall 状态，堆栈停在 runtime.gopark。这时候别盯着 CPU 火焰图，先看 /debug/pprof/goroutine?debug=2，搜 read、write、semacquire、chan receive 这些关键词。
常见误判：看到某个 handler 函数在 top 列表里占比高，就以为是它慢。其实它可能只是“挂”在那里等数据库或下游 HTTP 响应——真正瓶颈在外部调用，而非函数本身。
- 如果大量 goroutine 停在
net.(*conn).Read或io.ReadFull，说明 socket 没数据且没设超时 - 如果停在
http.(*persistConn).roundTrip，重点查Transport的DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout - 如果停在
database/sql.(*DB).conn，不是网络问题，是连接池枯竭或 DB 侧卡顿
http.Client 超时必须分三层配，漏一层就可能卡死
http.Client.Timeout 是兜底项，只管从发起请求到读完全部响应体的总时间；它不覆盖 DNS 解析、TCP 建连、TLS 握手、首字节等待这些中间环节。实际中，80% 的“卡住”发生在建连或等 header 阶段，而非 body 传输。
正确配置示例：
立即学习“go语言免费学习笔记（深入）”；
client := &http.Client{
Timeout: 5 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 1 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 2 * time.Second,
ResponseHeaderTimeout: 3 * time.Second,
IdleConnTimeout: 30 * time.Second,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
},
}-
DialContext.Timeout控制 DNS + TCP SYN + SYN-ACK 全过程，跨机房场景建议不小于 1.5s -
TLSHandshakeTimeout单独约束 TLS 握手，公网环境易受中间设备干扰，设 2–3s 较稳妥 -
ResponseHeaderTimeout是最常被忽略的一环：服务端写完 header 就卡住（比如 DB 查询未返回），这个超时能及时中断，避免等几十秒 - 别复用
http.DefaultClient，它的超时是 0，且连接池全局共享，其他模块可能悄悄改掉参数
tcpdump 是唯一能确认真实网络耗时的手段
Span.End() 或日志打点测出的“耗时 280ms”，和真实链路耗时不一致，是因为观测点太靠上：SYN-ACK 往返、TLS record 交换、NAT 设备重传这些都发生在应用层之下。你看到的只是“应用认为完成的时间”，不是“数据真正发出去/收回来的时间”。
快速验证步骤：
- 在服务端或客户端机器上跑：
sudo tcpdump -i any -w trace.pcap port 443 or port 80 - 复现一次慢请求，停止抓包，用 Wireshark 打开，过滤
http || tls - 找对应请求的 TCP 流，看
Syn → Syn-Ack → Ack耗时（建连）、Client Hello → Server Hello（TLS）、第一个 HTTP data 包到第一个 response data 包（端到端） - 若 SYN-ACK 就占 60ms，而 Span 显示总耗时 220ms，那至少有 60ms 是纯网络抖动，优化代码无意义
注意：云厂商 SLB、F5、ALB 等中间设备可能引入额外延迟，且不暴露给应用层——tcpdump 在客户端抓，才能看到全链路。
跨机房调用必须隔离连接池和 tracer 观测点
同一个 http.Client 复用连接池，但北京和新加坡的 user-service.prod.internal 经 DNS 解析后 IP 不同，MaxIdleConnsPerHost 按 Host 字符串隔离，无法区分物理位置。结果就是连接池混用，空闲连接错配，频繁重建连接，P99 毛刺飙升。
同时，OpenTelemetry 的 Span.End() 在服务端 WriteHeader 时触发，此时数据还在 TCP 缓冲区，SYN-ACK/TLS/NAT 等耗时全丢失。
- 为每个机房 endpoint 单独初始化
http.Client，Transport 设置独立MaxIdleConns和IdleConnTimeout - 补
net.Conn级建连耗时：用Transport.DialContexthook 记录dialer.DialContext耗时 - 补请求级往返耗时：用自定义
RoundTripper在Write后打点，在Read后结束，覆盖 TCP 缓冲区阶段 - LB 清洗
traceparent头？检查是否启用underscores_in_headers on，或强制用 W3C 标准头并显式设置 propagator
网络延迟不是“代码写得不够快”的问题，而是观测盲区、配置错位和基础设施不可见性共同导致的——定位时，先信 tcpdump，再信 pprof，最后才看业务逻辑。
