curl 接口调试速记：状态码、耗时与重试

接口不通时，先别急着改代码：用 curl 把一次请求拆成状态码、耗时、响应体三段来看，多数问题两分钟内就能定位到哪一层。

一、先看状态码：定问题层级

curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/health

200 是服务正常；301/302 看 Location 是否跳错了域名；401/403 查鉴权头与令牌是否过期；404 先核对路径与请求方法；500/502/503 属于服务端或网关侧，优先看服务端日志，而不是反复重试。-o /dev/null 丢弃响应体，只保留状态码，输出干净。

二、测耗时：分清哪一段慢

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

time_namelookup 高是 DNS 问题，换 DNS 或检查解析；time_connect 高是网络或端口不通；time_starttransfer 高是服务端处理慢；total 接近 ttfb 说明传输本身不慢。加 --max-time 10 防止请求挂死。

三、看响应体与请求头：核对细节

curl -s -i https://api.example.com/users | head -n 20

-i 同时输出响应头和响应体，确认 Content-Type 与字符集；用 -H "Authorization: Bearer xxx" 补鉴权头，用 -d '{"name":"demo"}' 发 POST 请求体，用 -X PUT 指定方法。返回乱码先看 charset，再检查是否被压缩，可加 --compressed。

四、失败要重试，但别无脑重试

curl --retry 3 --retry-delay 2 --retry-all-errors https://api.example.com/sync

--retry 只对瞬时错误有效，连续三次失败就应停下来看日志；POST 等非幂等请求默认不重试，确需重试要确认接口支持幂等。502/503 可以退避重试，400/401 反复重试没有意义。

小结

调接口的顺序固定下来：先状态码定层级，再分段耗时定慢点，再用 -i 核对头与体，最后有节制地重试。把上面四条命令存成速记，遇到接口问题先跑一遍，大多数故障不用进代码就能定位。