调接口最怕什么？命令不是返回一堆报错，是检查接口你压根不知道它到底通没通。上周同事老周排查一个支付回调问题，命令折腾到凌晨两点，检查接口最后发现是命令对方接口地址多了个斜杠。他拍桌子骂了一句：“就没个命令能先探探路吗？检查接口”有。而且不止一个。命令

curl 是检查接口最顺手的那把螺丝刀。别被它那堆参数吓住，命令日常检查接口，检查接口记住三四个就够用。命令比如你想看某个服务是检查接口否活着：

curl -I https://api.example.com/health

加个 -I 只取响应头，不下载正文。命令返回 HTTP/2 200，检查接口说明服务在喘气；返回 502 或 503，命令那就是网关或后端挂了。老周那次如果先跑这条命令，看到 301 重定向，立马就能察觉地址有问题。

光看状态码不够。接口返回的 JSON 里藏着更细的线索。我习惯加 -s 静默模式，再用 -w 把关键指标打出来：

curl -s -o /dev/null -w "状态码:%{ http_code} 耗时:%{ time_total}s\n" https://api.example.com/orders/123

这行命令把响应体丢进黑洞，只留状态码和总耗时。耗时突然从 200ms 飙到 2s，多半是数据库慢查询或者下游服务拖后腿。别小看这个数字，它比日志里那些“请求成功”的废话有用得多。

有时候接口需要带 token 或特定 header 才肯干活。直接 -H 塞进去：

curl -H "Authorization: Bearer abc123" -H "Accept: application/json" https://api.example.com/user/profile

返回 401 就是 token 过期或格式不对，403 是权限不够。这两个码经常被搞混，其实区别很直白：401 是“你是谁我不认识”，403 是“我知道你是谁，但你没资格”。

POST 请求稍微麻烦点，要指定方法和数据体。别用 -d 直接拼字符串，引号转义能把你逼疯。用 --data @file.json 从文件读，干净利落：

curl -X POST -H "Content-Type: application/json" --data @payload.json https://api.example.com/orders

如果返回 400，先别怀疑接口逻辑，拿 jq 把 payload 格式化看一眼。十有八九是字段名拼错或者少了必填项。我见过有人把 userId 写成 user_id，查了三小时。

还有一类场景：接口通了但返回的数据不对。这时候光看状态码没用，得把响应体拽下来比对。用 curl -s ... | jq '.data.items[0]' 直接切到具体字段，比肉眼扫一大坨 JSON 快得多。jq 这个工具，装一次受益终身。

有人问，Postman 图形界面不香吗？香。但服务器上没浏览器，Docker 容器里更不可能开 GUI。命令行检查接口，图的就是随时随地、不挑环境。而且脚本化之后，可以塞进 CI 流水线，每次部署完自动跑一遍健康检查。这才是它真正省事的地方。

最后说个坑。curl 默认不跟随重定向，遇到 301 就停住。加 -L 才会跟到底。但别无脑加，有些接口故意用重定向做鉴权跳转，跟过去反而拿到登录页的 HTML。看清楚返回头里的 Location 再决定。

命令检查接口这事，说到底就是：先探活，再看码，再验数据。三步走完，问题基本定位。别一上来就翻代码，先让 curl 说句话。