接口调不通别先怀疑代码：用 curl 分四步定位问题

标题：《接口调不通别先怀疑代码：用 curl 分四步定位问题》

接口调不通时，很多人第一反应是翻代码、改参数，来回折腾半天才发现问题根本不在代码里。更省事的做法是先用 curl 把请求拆开看：它到底连上了没有、服务器回了什么、卡在哪一步。把这四步走完，大多数接口问题都能定位到具体的环节。

第一步先看能不能连上。用 curl -v https://api.example.com/health，-v 会打印出 DNS 解析、TCP 连接、TLS 握手和请求头。如果卡在 DNS 阶段，报错往往是 Could not resolve host，这时先查域名本身：换个网络试试，或者用 nslookup、dig 确认解析结果，别急着改代码里的地址。如果卡在连接超时，大概率是网络不通或端口没放行，先确认服务地址和端口对不对，再看防火墙和安全组。

第二步看状态码。连接通了不等于接口对了：404 说明路径写错了，先对照接口文档核对路径和方法；401 或 403 说明认证出了问题，检查 Token 是否过期、请求头里的 Authorization 格式对不对；500 则是服务端内部错误，这时光看客户端没用，得去服务端日志里找对应的报错时间点。状态码先把问题分到“客户端”还是“服务端”，能省掉很多无用功。

第三步看返回体和请求头。状态码正常但数据不对时，用 curl -s 加上 -H 逐项确认请求头：Content-Type 是不是 application/json、Token 有没有带上、参数是不是放在了正确的位置。POST 请求尤其容易在这里踩坑：参数放在 URL 里还是放在 body 里、JSON 格式有没有多一个逗号，都会让服务端解析失败。把 curl 命令原样贴到终端跑一次，和代码里发出的请求逐项对比，往往一眼就能看出差异。

第四步看耗时和超时。如果接口偶尔才失败，先加 -w 输出耗时分段：DNS、连接、TLS、首字节各花了多久。首字节慢说明服务端处理慢，要去看服务端性能；连接阶段慢则多半是网络问题。另外注意 curl 默认没有超时限制，接口 hang 住时终端会一直等着，排查时加上 --max-time 10，超时就果断断开，避免把一次排查变成漫长的等待。

养成这个顺序后，排查就有了固定套路：先连通性、再状态码、再请求细节、最后看耗时。每一层都有明确的判断标准，不用靠猜。定位清楚再动手改代码，改动才有针对性，也不会把一个网络问题改成代码问题，或者把一个认证问题改成配置问题。