curl 命令怎么用？我平时调接口基本靠它

骑着bug的coder
3 阅读8分钟

curl 命令怎么用？我平时调接口基本靠它

只要你平时写接口、联调前后端，或者经常和 HTTP 请求打交道，curl 这个命令基本躲不过。

我第一次接触它的时候，其实有点抗拒。 一串参数堆在一起，看着就不像什么“友好工具”：

curl -X POST https://example.com/api \
  -H "Content-Type: application/json" \
  -d '{"name":"Tom"}'

但用久了之后会发现，这东西是真的省事。

很多时候我只是想确认一个接口通不通、参数有没有带对、服务端到底回了什么。 这种场景下，开 Postman 有点重，专门写个页面更没必要，直接一条 curl 就够了。

这篇文章不打算讲太多官方定义，就按平时最常用的场景过一遍。 目标也很直接：看完之后，你至少能自己写出常见的 GET、POST、带 JSON、带 token 的请求。

先把 curl 想简单一点

你可以把 curl 理解成一句话：

它就是在命令行里发 HTTP 请求。

比如这条命令：

curl -X POST example.com/api/users
-H "Content-Type: application/json"
-d '{"name":"Tom","age":18}'

别看它长，其实就是在说：

  • 我要发一个 POST
  • 地址是 example.com/api/users
  • 请求头里告诉服务端：我传的是 JSON
  • 请求体里有一段数据

说白了，它不是新东西，只是把平时接口请求的那些信息换成了命令行写法。

  1. 最基本的用法：直接请求一个地址

最简单的写法就是：

curl example.com

默认就是 GET 请求。

如果这个地址返回的是网页，你会在终端里看到 HTML。 如果这是个接口，通常会返回 JSON。

比如拿这个站点练手就挺方便：

curl httpbin.org/get

它会把你这次请求的信息再回给你，刚入门的时候很适合拿来试。

  1. 如果想看响应头，用 -i

有时候你不只是想看返回内容，还想知道：

  • 状态码是多少
  • 返回了哪些 header
  • 有没有发生跳转

这时候就加个 -i：

curl -i example.com

它会把响应头和响应体一起打出来。

如果你只想看响应头，不关心正文，那就用：

curl -I example.com

这个我平时查接口状态挺常用的。

  1. 指定请求方法：-X

虽然 curl 默认就是 GET，但实际开发里，更多时候还是发 POST、PUT、DELETE。

发 POST

curl -X POST example.com/api/users

发 PUT

curl -X PUT example.com/api/users/1

发 DELETE

curl -X DELETE example.com/api/users/1

-X 就是指定请求方法。

不过如果本来就是 GET，就别特地写 -X GET 了，没必要。

  1. URL 上带参数

比如分页接口，经常会这么写：

curl "example.com/api/users?p…"

这里最好带上双引号。 因为 URL 里如果有 &，shell 可能会把它当成别的东西处理。

这是个小细节，但新手确实很容易踩这个坑。

  1. 发 JSON 请求，这是最常见的

平时调接口，最常见的就是发 JSON。

比如新增一个用户：

curl -X POST example.com/api/users
-H "Content-Type: application/json"
-d '{"name":"Tom","age":18}'

这里就两个关键参数：

  • -H：加请求头
  • -d：带请求体数据

如果你传的是 JSON，通常都别忘了这一句：

-H "Content-Type: application/json"

不然有些后端会按表单去解析，最后表现出来就是： 命令是跑了，但服务端拿到的数据不对。

这种问题我自己刚接触接口的时候没少遇到。

  1. 发表单也行

除了 JSON，表单请求也很常见。

普通表单提交

curl -X POST example.com/login
-d "username=tom&password=123456"

这种就是最普通的表单格式。

上传文件

如果是上传文件，用 -F：

curl -X POST example.com/upload
-F "file=@./test.png"

这个 @ 很关键，表示上传本地文件。

如果还要额外传点别的字段，也可以一起带：

curl -X POST example.com/upload
-F "file=@./test.png"
-F "userId=123"

这在测试上传接口的时候很方便，不用专门写个页面。

  1. 带 token 鉴权

现在很多接口都会要求带 token。

比如 Bearer Token：

curl example.com/api/profile
-H "Authorization: Bearer YOUR_TOKEN"

这个写法很常见，平时调用需要登录态的接口时基本都会碰到。

如果是最基础的账号密码认证，也可以这么写：

curl -u username:password example.com/api/profile

  1. 下载文件

curl 不只是拿来调接口，也能直接下载东西。

用远程文件名保存

curl -O example.com/file.zip

自己指定保存名

curl -o myfile.zip example.com/file.zip

区别不复杂：

  • -O 用服务端原始文件名
  • -o 用你自己写的名字
  1. 有跳转时记得加 -L

有些地址会 301、302 跳到另一个地址。 这时候如果你不加参数，可能拿到的只是跳转响应，不是最终内容。

所以很多时候我会顺手加上：

curl -L example.com

-L 的意思就是跟着跳转继续请求。

这个参数看起来不起眼，但挺实用。

  1. 查问题时，-v 很有用

如果你怀疑请求哪里不对，最直接的方法就是开详细模式：

curl -v example.com

这样你能看到很多过程信息，比如：

  • 实际发了哪些请求头
  • 服务端回了什么
  • 有没有发生重定向
  • TLS 握手有没有问题

有时候接口调不通，不一定是后端挂了，也可能是你 header 写错了，或者请求根本没按你以为的方式发出去。 这种时候 -v 很顶用。

  1. 只看状态码

有时候我只是想快速确认一个接口是不是 200，不想看一大坨响应内容。

这种时候会这么写：

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

输出就只有一个状态码，比如：

200

这条命令看着稍微有点“命令行味儿”，但在脚本里特别常用。

简单理解就是：

  • 返回体不要了
  • 过程别啰嗦
  • 最后只告诉我状态码
  1. Cookie 也能带

如果接口依赖 Cookie，也能直接处理。

手动带 Cookie

curl example.com
-H "Cookie: sessionId=abc123"

先保存，再复用

curl -c cookies.txt example.com/login curl -b cookies.txt example.com/profile

  • -c：保存 Cookie
  • -b：读取 Cookie

如果你想模拟登录后的请求，这种方式挺省事。

  1. 本地 HTTPS 有问题时，可以先用 -k

有时候本地环境的 HTTPS 证书不规范，直接请求会报错。

这时候可以先跳过校验：

curl -k https://localhost:8443

这个参数平时开发阶段偶尔会用到。 但线上环境还是别这么搞，能校验证书还是要校验。

  1. 为什么我觉得它特别适合 Claude Code CLI 这种环境

我自己一直没把 curl 换掉，还有个很现实的原因： 如果你本来就在命令行里工作，它会特别顺手。

像 Claude Code CLI 这种环境，本来很多事情就在终端里完成：

  • 看代码
  • 改代码
  • 跑测试
  • 查日志
  • 启服务
  • 验接口

这时候如果还专门切到浏览器或者别的图形界面工具，多少会打断一点节奏。 反而是 curl 这种命令行工具，更容易直接接进整个工作流里。

比如你刚改完一个接口，想确认服务是不是正常返回，顺手就是一条：

curl -i "http://localhost:3000/api/users"

如果要测带 token 的请求，也可以马上补一条：

curl "http://localhost:3000/api/profile"
-H "Authorization: Bearer your_token"

这种体验挺适合 CLI 驱动的开发方式。 你不用离开当前上下文，改完代码就验证，验证完继续改。整个过程是连着的。

所以对我来说，curl 不只是一个“会用就行”的命令。 在 Claude Code CLI 这种环境里，它更像是一个很基础、很顺手的日常工具。

  1. 新手先记住这几个参数就够了

刚开始学 curl，不用想着一次全记住。 先把下面这些高频参数混熟，已经够用了：

┌──────┬─────────────────────┐ │ 参数 │ 作用 │ ├──────┼─────────────────────┤ │ -X │ 指定请求方法 │ ├──────┼─────────────────────┤ │ -H │ 添加请求头 │ ├──────┼─────────────────────┤ │ -d │ 发送请求体 │ ├──────┼─────────────────────┤ │ -F │ 上传文件 / 表单提交 │ ├──────┼─────────────────────┤ │ -i │ 显示响应头和响应体 │ ├──────┼─────────────────────┤ │ -I │ 只看响应头 │ ├──────┼─────────────────────┤ │ -L │ 跟随重定向 │ ├──────┼─────────────────────┤ │ -o │ 保存到指定文件 │ ├──────┼─────────────────────┤ │ -O │ 用远程文件名保存 │ ├──────┼─────────────────────┤ │ -v │ 显示详细过程 │ ├──────┼─────────────────────┤ │ -s │ 静默模式 │ ├──────┼─────────────────────┤ │ -u │ Basic Auth │ ├──────┼─────────────────────┤ │ -k │ 忽略 HTTPS 证书校验 │ └──────┴─────────────────────┘

我自己的感觉是，-H、-d、-X、-L、-v 这几个用得最多。

  1. 几个特别容易踩的坑

1）URL 里有 &，没加引号

错误写法：

curl example.com/api?a=1&b=2

更稳一点：

curl "example.com/api?a=1&b=2"

2）传 JSON，但没写 Content-Type

错误写法：

curl -X POST example.com/api
-d '{"a":1}'

更稳的写法：

curl -X POST example.com/api
-H "Content-Type: application/json"
-d '{"a":1}'

3）命令没报错，不代表请求就对了

这个真的挺常见。

curl 能执行成功，只说明命令格式没问题。 但服务端到底有没有收到你想传的内容，还是得看响应、状态码，必要时开 -v。

有时候问题不是接口挂了，而是你自己 header 少写了一个。

  1. 平时最常用的几个模板

GET 请求

curl "api.example.com/users?page=…"

POST JSON

curl -X POST "api.example.com/users"
-H "Content-Type: application/json"
-d '{"name":"Alice","email":"alice@example.com"}'

带 token

curl "api.example.com/me"
-H "Authorization: Bearer abcdefg"

上传文件

curl -X POST "api.example.com/upload"
-F "file=@./demo.pdf"

只看响应头

curl -I "example.com"

  1. 最后说个我自己的感受

学 curl 这件事，重点不是把所有参数都背下来。

重点是你先知道一个 HTTP 请求到底由什么组成：

  • 方法
  • 地址
  • 请求头
  • 请求体

这个想通之后，curl 就没那么吓人了。 它本质上只是把这些东西翻译成命令而已。

而且如果你本来就习惯在命令行里工作，比如在 Claude Code CLI 这种环境下写代码、跑测试、查服务，那 curl 会特别顺手。 你不需要切换工具，改完代码就能直接验证接口，整个节奏是连着的。

它不一定是最花哨的工具，但很多时候，它真的是最快的那个。

avatar
文章
阅读
粉丝