curl 超时别只加 --max-time：用 -w 分段计时先定位慢在哪一段

调用接口超时时，最常见的反应是把超时时间调大。调大能让请求跑完，却掩盖了真正的问题：慢的是 DNS 解析、TCP 建连、TLS 握手，还是服务器处理？不同阶段慢，对应的修法完全不同。curl 自带的 -w 分段计时，可以在不装任何工具的情况下把一次请求拆开看。

先用一条命令拿到分段数据：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com/api

这几个字段的含义很直观：time_namelookup 是 DNS 解析耗时，time_connect 是 TCP 建连耗时，time_appconnect 是 TLS 握手完成的时间点，time_starttransfer 是收到第一个字节的时间点，time_total 是总耗时。两两相减，就能得到每一段的耗时：DNS 段就是 time_namelookup，建连段是 time_connect 减 time_namelookup，TLS 段是 time_appconnect 减 time_connect，服务器处理段是 time_starttransfer 减 time_appconnect，传输段是 time_total 减 time_starttransfer。

定位方法按段来：如果 DNS 一段就占了几秒，先查本机 DNS 配置和解析链路，而不是去调接口超时；如果建连慢，多半是网络路径或目标端口层面的问题；如果 TLS 段突然变长，留意证书链验证和服务端握手配置；如果前面都很快、唯独 time_starttransfer 很大，说明请求已经到了服务端，是服务端处理慢，这时才值得去看慢查询、锁等待或者下游依赖；如果 time_starttransfer 正常、total 却很大，说明是响应体传输慢，可能是包体过大或带宽受限，考虑分页、压缩或断点续传。

还有两个容易踩的坑。第一，只测一次没有意义：网络抖动会让单次数据失真，至少连测三次，看哪一段稳定地偏高。第二，不要在生产接口上反复压测分段计时，确认问题后就停手，压测要去测试环境做。

分段计时最大的好处，是把“接口慢”这个模糊的抱怨变成一张可以逐项排除的清单。下次再遇到超时，先跑一次 -w，看清是哪一段在拖时间，再决定是改配置、修服务端，还是真的需要放宽超时。