1. 从“网络瑞士军刀”说起为什么你离不开curl如果你在Linux世界里待过一阵子或者哪怕只是偶尔在终端里敲敲打打大概率都见过或者用过curl这个命令。它太常见了常见到很多人觉得它就是个“下载工具”输入curl -O后面跟个网址文件就下来了。但如果你真这么想那可就太小看它了。在我十多年的运维和开发经历里curl的地位不亚于一把“网络瑞士军刀”——它小巧、锋利几乎能处理所有跟HTTP、HTTPS、FTP等协议相关的网络操作。从最简单的检查一个网页能否访问到模拟复杂的API请求、调试微服务接口、甚至测试负载均衡和SSL证书curl都是那个你第一时间会想到的工具。为什么它如此重要首先它是无头headless的这意味着它不依赖图形界面可以在任何服务器、任何脚本、任何自动化流程中运行。其次它协议支持极其广泛HTTP、HTTPS、FTP、SFTP、SCP、TELNET……几乎涵盖了所有主流的数据传输协议。最后它功能强大且灵活通过上百个命令行参数你可以精细控制请求的每一个细节请求头、请求体、认证信息、代理、超时、重定向等等。很多图形化的API测试工具比如Postman在底层其实也是调用类似curl的命令。所以今天我们不聊那些高深莫测的底层原理就从一个一线工程师的视角掰开揉碎地讲讲curl在日常工作中最高频、最实用的十种用法。我会结合具体的场景告诉你为什么这么用以及背后可能遇到的“坑”。无论你是刚接触Linux的新手还是需要频繁调试接口的开发者或者是负责维护服务的运维这篇文章都能让你对curl有一个全新的、更深入的认识并直接提升你的工作效率。2. 基础诊断你的服务还活着吗状态检查与基础信息获取这是curl最朴素也最不可或缺的用途。当服务出现异常你的第一反应不应该是打开浏览器而是打开终端。2.1 最简单的连通性测试-I 与 -v假设你刚部署了一个新的Web服务在http://192.168.1.100:8080上怎么最快确认它启动成功了很多人会用curl http://192.168.1.100:8080这会返回整个网页的HTML内容。如果页面很大输出会刷屏我们其实只关心服务是否响应。这时-I大写字母I参数就派上用场了。它代表--head意思是只请求服务器的响应头而不下载正文。curl -I http://192.168.1.100:8080执行后你会看到类似这样的输出HTTP/1.1 200 OK Server: nginx/1.18.0 Date: Mon, 01 Jan 2024 12:00:00 GMT Content-Type: text/html; charsetutf-8 Connection: keep-alive看到HTTP/1.1 200 OK基本就能断定服务端口是通的并且能正常处理HTTP请求。这比用telnet测试端口更“HTTP友好”。但有时候200 OK并不代表一切正常。比如你的服务可能因为配置错误返回了一个成功的状态码但内容却是错误页面。或者你遇到了重定向、认证失败等问题。这时你需要更详细的调试信息。-vverbose详细模式是你的最佳选择。curl -v http://192.168.1.100:8080-v会输出整个HTTP交互的“剧本”包括你发出的请求头和服务器返回的响应头。这对于诊断问题至关重要。例如你可以清楚地看到 GET / HTTP/1.1 发出的请求行。 Host: 192.168.1.100:8080 发出的请求头。 HTTP/1.1 301 Moved Permanently 服务器返回的状态码如果是重定向。 Location: https://192.168.1.100:8080/ 重定向的目标地址如果状态码是3xx。以及SSL握手的过程如果用了HTTPS。实操心得我习惯将-I和-v结合使用即curl -Iv。这样既能快速看到最终状态码和关键响应头又能看到详细的交互过程效率最高。特别是在排查一些诡异的跨域CORS问题或者代理问题时请求头里是否携带了正确的Origin或Host字段一目了然。2.2 跟随重定向-L在Web开发中重定向301/302非常普遍。比如你访问http的站点它可能会自动跳转到https。如果你用普通的curl命令它默认不会自动跟随重定向而是会停在那里告诉你收到了一个301 Moved Permanently或302 Found的响应。curl -I http://example.com # 可能返回HTTP/1.1 301 Moved Permanently Location: https://example.com/对于自动化脚本或者只是想拿到最终内容的你来说这很不方便。-L--location参数就是用来解决这个问题的。它会像浏览器一样自动跟随重定向直到拿到最终的响应。curl -L -I http://example.com # 这次会返回最终目标https://example.com的响应头如 HTTP/2 200注意事项使用-L时要小心循环重定向。如果服务器配置错误导致A重定向到BB又重定向回Acurl默认会跟随最多50次可通过--max-redirs修改然后报错退出。在脚本中使用时最好结合--max-redirs 10来限制次数避免脚本卡死。3. 数据传输不仅仅是下载GET/POST/PUT/DELETEcurl的核心功能是传输数据。它天然支持 RESTful API 的各种动词是API测试和调试的利器。3.1 下载文件-O, -o, 与 -J下载文件是基本操作但这里面的门道不少。-O大写字母O这是最常用的。它会使用远程文件在服务器上的名字将文件保存到当前目录。curl -O https://example.com/path/to/file.zip # 下载后本地文件名为 file.zip-o小写字母o允许你指定下载后本地文件的名称。curl -o mybackup.zip https://example.com/path/to/file.zip # 下载后本地文件名为 mybackup.zip-J--remote-header-name这是一个非常有用但常被忽略的参数。有时服务器会在响应头中通过Content-Disposition字段提供一个建议的文件名这个文件名可能更准确比如包含了时间戳或版本号。-J会尝试使用这个建议的文件名。通常与-O或-o结合使用。curl -OJ https://example.com/download/latest # 如果服务器响应头里有 Content-Disposition: attachment; filenameapp-v2.1.0.tar.gz # 那么下载到本地的文件就会是 app-v2.1.0.tar.gz而不是 “latest”踩坑记录我曾经用脚本定期下载一个日志文件源地址不变。一开始用-O没问题。后来服务器端更新在响应头里加了Content-Disposition指定了带日期的文件名但我脚本没改导致每天下载的文件都叫同一个名字把前一天的覆盖了。加上-J参数后问题解决每天的文件都能按日期正确保存。3.2 发送POST请求与提交表单-d 与 -F与API交互POST请求是家常便饭。发送JSON数据这是现代API最常见的格式。使用-d--data参数并设置正确的Content-Type请求头。curl -X POST https://api.example.com/users \ -H Content-Type: application/json \ -d {name: 张三, email: zhangsanexample.com}-X POST可以省略因为当使用-d时curl默认的请求方法就是 POST。-H用于添加请求头。发送表单数据application/x-www-form-urlencoded同样使用-d但数据格式是key1value1key2value2并且通常不需要显式指定Content-Typecurl会自动设置为application/x-www-form-urlencoded。curl -X POST https://api.example.com/login \ -d usernameadminpasswordsecret上传文件multipart/form-data当需要上传文件时比如网页上的文件选择框就需要使用-F--form参数。curl -X POST https://api.example.com/upload \ -F file/home/user/picture.jpg \ -F caption这是一张风景照符号告诉curl后面跟的是文件路径。-F会自动将Content-Type设置为multipart/form-data。核心原理-d和-F的本质区别在于对请求体的编码方式。-d是简单的键值对编码可以是JSON或URL编码而-F会将每个字段包括文件作为多部分multipart消息体的一部分进行编码每个部分都有自己的头部信息如文件名、内容类型。这就是为什么上传文件必须用-F。3.3 发送PUT、DELETE等请求-X对于RESTful APIPUT用于更新DELETE用于删除。使用-X--request参数可以指定任何HTTP方法。# 更新资源 curl -X PUT https://api.example.com/users/123 \ -H Content-Type: application/json \ -d {email: new_emailexample.com} # 删除资源 curl -X DELETE https://api.example.com/users/1234. 高级调试与性能洞察当基础功能无法定位问题时你需要更强大的工具。4.1 测量请求各阶段耗时-w 与 --trace-time性能优化时我们需要知道时间花在了哪里。-w--write-out参数可以输出格式化的信息其中包含一系列关于时间和性能的变量。一个非常实用的格式字符串是curl -w \n\n时间统计:\n DNS解析: %{time_namelookup} 秒\n 建立TCP连接: %{time_connect} 秒\n SSL握手如适用: %{time_appconnect} 秒\n 从开始到收到第一个字节TTFB: %{time_starttransfer} 秒\n 总耗时: %{time_total} 秒\n \ -o /dev/null -s https://www.example.com解释一下-o /dev/null 将输出内容丢弃到“黑洞”我们只关心时间数据。-s 静默模式不显示进度条或错误信息让输出更干净。%{time_namelookup} DNS域名解析耗时。%{time_connect} 建立TCP连接的耗时。%{time_appconnect} 建立SSL/TLS连接的耗时仅HTTPS。%{time_starttransfer} 从请求开始到收到服务器第一个响应字节的耗时TTFBTime To First Byte。这是衡量服务器响应速度的关键指标。%{time_total} 请求总耗时。通过这个输出你可以快速定位瓶颈。如果time_namelookup很大可能是DNS服务器慢如果time_connect很大可能是网络延迟高或服务器负载大如果time_starttransfer很大但time_connect很小那很可能是服务器应用本身处理慢。另一个有用的参数是--trace-time它会在-v输出的每一行前面加上时间戳让你看到请求和响应发生的精确时间点对于分析复杂的交互序列很有帮助。4.2 模拟特定客户端-A 与 -H有些服务器会根据User-Agent请求头返回不同的内容比如针对移动端和桌面端的页面。-A--user-agent可以让你伪装成任何客户端。curl -A Mozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X) AppleWebKit/605.1.15 https://example.com更通用的方法是使用-H直接设置任何请求头这在测试API鉴权、内容协商时必不可少。# 发送一个接受JSON格式的API请求 curl -H Accept: application/json https://api.example.com/data # 携带Bearer Token进行认证 curl -H Authorization: Bearer eyJhbGciOiJ... https://api.example.com/protected # 模拟来自特定来源的请求用于测试CORS curl -H Origin: http://localhost:3000 -v https://api.example.com/data4.3 处理Cookie-b 与 -cWeb应用离不开Cookie。curl可以发送和保存Cookie。-c file 将服务器返回的Cookie保存到指定文件。curl -c cookies.txt https://example.com/login -d useradminpass123-b file 从指定文件读取Cookie并随请求发送。也可以直接用字符串指定。# 从文件读取 curl -b cookies.txt https://example.com/dashboard # 直接指定Cookie字符串 curl -b sessionidabc123; usernameadmin https://example.com/dashboard这在进行需要登录会话的自动化测试时非常有用。你先用curl模拟登录并保存Cookie后续的请求都带上这个Cookie就能维持会话状态。5. 安全与稳定性保障在生产环境或处理重要数据时安全性和脚本的健壮性必须考虑。5.1 处理HTTPS与SSL证书在测试环境你可能会遇到自签名证书curl默认会拒绝连接并报错SSL certificate problem: self signed certificate。有几种处理方式-k或--insecure最不推荐但最方便。它告诉curl忽略所有SSL证书验证错误。仅在测试自己完全可控的、无关安全的内网服务时使用绝对不要在对公网或生产环境服务时使用。curl -k https://internal-test-server指定自定义CA证书推荐做法。如果你有自己的内部CA证书颁发机构可以将CA证书文件告诉curl。curl --cacert /path/to/company-ca.pem https://internal-server使用--cert和--key 如果服务端要求客户端证书认证双向TLS你需要提供自己的客户端证书和私钥。curl --cert /path/to/client.pem --key /path/to/client-key.pem https://secure-api.example.com5.2 控制超时与重试网络不稳定是常态你的脚本必须有容错能力。连接超时--connect-timeout 限制建立TCP连接的最长时间。如果服务器在指定秒数内没有响应SYN-ACK则放弃。curl --connect-timeout 10 https://example.com最大请求时间--max-time 限制整个curl操作的最长时间包括连接、传输等。这是防止脚本无限期挂起的最重要参数。curl --max-time 30 https://example.com/large-file失败重试--retry 当遇到瞬时的网络错误如连接超时、HTTP 5xx错误时自动重试。curl --retry 3 --retry-delay 5 https://example.com # 最多重试3次每次间隔5秒限制速度--limit-rate 避免curl占满带宽影响其他服务。curl --limit-rate 200K -O http://example.com/bigfile.iso # 将下载速度限制在每秒200KB经验之谈在编写用于监控或自动化部署的脚本时我几乎总是会加上--max-time和--retry参数。比如一个健康检查脚本curl -fsS --max-time 5 --retry 2 http://localhost:8080/health。-f--fail参数让curl在服务器返回HTTP错误状态码400时以非0状态退出这对于脚本判断成功失败非常关键。-sS是-s静默加上-S--show-error这样在失败时仍会显示错误信息但平时不输出无关内容。6. 实战串联一个完整的API测试与调试案例让我们把这些用法串起来模拟一个真实的场景你作为后端开发者需要测试一个刚开发完成的用户注册API。首先检查服务是否可达并查看基础信息curl -I http://localhost:8080/api/register如果返回404可能是路由不对如果返回405 Method Not Allowed说明这个端点不支持GET方法需要用POST。发送一个POST请求进行注册curl -X POST http://localhost:8080/api/register \ -H Content-Type: application/json \ -d {username: testuser, password: TestPass123, email: testexample.com} \ -v使用-v查看详细的请求和响应。假设服务器返回201 Created和一个包含用户ID的JSON体以及一个Set-Cookie头。假设注册成功并设置了会话Cookie我们保存这个Cookiecurl -X POST http://localhost:8080/api/register \ -H Content-Type: application/json \ -d {username: testuser2, password: TestPass123, email: test2example.com} \ -c session.cookie \ -s使用保存的Cookie测试需要登录才能访问的“获取用户信息”APIcurl -b session.cookie http://localhost:8080/api/user/profile -v观察请求是否自动带上了Cookie以及服务器是否返回了正确的用户信息。进行性能基准测试curl -w TTFB: %{time_starttransfer}s, 总时间: %{time_total}s\n \ -o /dev/null \ -b session.cookie \ http://localhost:8080/api/user/profile多次运行这个命令可以获取一个粗略的响应时间分布。模拟异常情况测试密码太短的错误。curl -X POST http://localhost:8080/api/register \ -H Content-Type: application/json \ -d {username: short, password: 123, email: ab.c} \ -f因为密码不符合规则服务器应该返回400 Bad Request。我们加了-f参数所以curl会以非0状态退出我们的脚本可以据此判断测试用例失败。通过这一套组合拳你几乎可以完成一个API接口的所有功能性测试而无需打开任何图形化工具。这种命令行驱动的测试方式尤其适合集成到CI/CD流水线中实现自动化测试。curl的强大远不止于此它还能处理FTP上传下载、支持代理、进行带宽测试等。但上面这十种用法覆盖了日常开发和运维工作中90%以上的场景。记住工具的价值不在于你知道它有多少参数而在于在遇到问题时你能立刻想起并组合使用那几个最合适的参数来快速解决问题。把curl当成你终端里的老朋友多用它多琢磨它你的工作效率一定会提升一个档次。 
长河君 · 2026/8/12 10:42:57 · 阅读 1.2k curl命令实战指南：从网络诊断到API测试的10个核心用法
1. 从“网络瑞士军刀”说起为什么你离不开curl如果你在Linux世界里待过一阵子或者哪怕只是偶尔在终端里敲敲打打大概率都见过或者用过curl这个命令。它太常见了常见到很多人觉得它就是个“下载工具”输入curl -O后面跟个网址文件就下来了。但如果你真这么想那可就太小看它了。在我十多年的运维和开发经历里curl的地位不亚于一把“网络瑞士军刀”——它小巧、锋利几乎能处理所有跟HTTP、HTTPS、FTP等协议相关的网络操作。从最简单的检查一个网页能否访问到模拟复杂的API请求、调试微服务接口、甚至测试负载均衡和SSL证书curl都是那个你第一时间会想到的工具。为什么它如此重要首先它是无头headless的这意味着它不依赖图形界面可以在任何服务器、任何脚本、任何自动化流程中运行。其次它协议支持极其广泛HTTP、HTTPS、FTP、SFTP、SCP、TELNET……几乎涵盖了所有主流的数据传输协议。最后它功能强大且灵活通过上百个命令行参数你可以精细控制请求的每一个细节请求头、请求体、认证信息、代理、超时、重定向等等。很多图形化的API测试工具比如Postman在底层其实也是调用类似curl的命令。所以今天我们不聊那些高深莫测的底层原理就从一个一线工程师的视角掰开揉碎地讲讲curl在日常工作中最高频、最实用的十种用法。我会结合具体的场景告诉你为什么这么用以及背后可能遇到的“坑”。无论你是刚接触Linux的新手还是需要频繁调试接口的开发者或者是负责维护服务的运维这篇文章都能让你对curl有一个全新的、更深入的认识并直接提升你的工作效率。2. 基础诊断你的服务还活着吗状态检查与基础信息获取这是curl最朴素也最不可或缺的用途。当服务出现异常你的第一反应不应该是打开浏览器而是打开终端。2.1 最简单的连通性测试-I 与 -v假设你刚部署了一个新的Web服务在http://192.168.1.100:8080上怎么最快确认它启动成功了很多人会用curl http://192.168.1.100:8080这会返回整个网页的HTML内容。如果页面很大输出会刷屏我们其实只关心服务是否响应。这时-I大写字母I参数就派上用场了。它代表--head意思是只请求服务器的响应头而不下载正文。curl -I http://192.168.1.100:8080执行后你会看到类似这样的输出HTTP/1.1 200 OK Server: nginx/1.18.0 Date: Mon, 01 Jan 2024 12:00:00 GMT Content-Type: text/html; charsetutf-8 Connection: keep-alive看到HTTP/1.1 200 OK基本就能断定服务端口是通的并且能正常处理HTTP请求。这比用telnet测试端口更“HTTP友好”。但有时候200 OK并不代表一切正常。比如你的服务可能因为配置错误返回了一个成功的状态码但内容却是错误页面。或者你遇到了重定向、认证失败等问题。这时你需要更详细的调试信息。-vverbose详细模式是你的最佳选择。curl -v http://192.168.1.100:8080-v会输出整个HTTP交互的“剧本”包括你发出的请求头和服务器返回的响应头。这对于诊断问题至关重要。例如你可以清楚地看到 GET / HTTP/1.1 发出的请求行。 Host: 192.168.1.100:8080 发出的请求头。 HTTP/1.1 301 Moved Permanently 服务器返回的状态码如果是重定向。 Location: https://192.168.1.100:8080/ 重定向的目标地址如果状态码是3xx。以及SSL握手的过程如果用了HTTPS。实操心得我习惯将-I和-v结合使用即curl -Iv。这样既能快速看到最终状态码和关键响应头又能看到详细的交互过程效率最高。特别是在排查一些诡异的跨域CORS问题或者代理问题时请求头里是否携带了正确的Origin或Host字段一目了然。2.2 跟随重定向-L在Web开发中重定向301/302非常普遍。比如你访问http的站点它可能会自动跳转到https。如果你用普通的curl命令它默认不会自动跟随重定向而是会停在那里告诉你收到了一个301 Moved Permanently或302 Found的响应。curl -I http://example.com # 可能返回HTTP/1.1 301 Moved Permanently Location: https://example.com/对于自动化脚本或者只是想拿到最终内容的你来说这很不方便。-L--location参数就是用来解决这个问题的。它会像浏览器一样自动跟随重定向直到拿到最终的响应。curl -L -I http://example.com # 这次会返回最终目标https://example.com的响应头如 HTTP/2 200注意事项使用-L时要小心循环重定向。如果服务器配置错误导致A重定向到BB又重定向回Acurl默认会跟随最多50次可通过--max-redirs修改然后报错退出。在脚本中使用时最好结合--max-redirs 10来限制次数避免脚本卡死。3. 数据传输不仅仅是下载GET/POST/PUT/DELETEcurl的核心功能是传输数据。它天然支持 RESTful API 的各种动词是API测试和调试的利器。3.1 下载文件-O, -o, 与 -J下载文件是基本操作但这里面的门道不少。-O大写字母O这是最常用的。它会使用远程文件在服务器上的名字将文件保存到当前目录。curl -O https://example.com/path/to/file.zip # 下载后本地文件名为 file.zip-o小写字母o允许你指定下载后本地文件的名称。curl -o mybackup.zip https://example.com/path/to/file.zip # 下载后本地文件名为 mybackup.zip-J--remote-header-name这是一个非常有用但常被忽略的参数。有时服务器会在响应头中通过Content-Disposition字段提供一个建议的文件名这个文件名可能更准确比如包含了时间戳或版本号。-J会尝试使用这个建议的文件名。通常与-O或-o结合使用。curl -OJ https://example.com/download/latest # 如果服务器响应头里有 Content-Disposition: attachment; filenameapp-v2.1.0.tar.gz # 那么下载到本地的文件就会是 app-v2.1.0.tar.gz而不是 “latest”踩坑记录我曾经用脚本定期下载一个日志文件源地址不变。一开始用-O没问题。后来服务器端更新在响应头里加了Content-Disposition指定了带日期的文件名但我脚本没改导致每天下载的文件都叫同一个名字把前一天的覆盖了。加上-J参数后问题解决每天的文件都能按日期正确保存。3.2 发送POST请求与提交表单-d 与 -F与API交互POST请求是家常便饭。发送JSON数据这是现代API最常见的格式。使用-d--data参数并设置正确的Content-Type请求头。curl -X POST https://api.example.com/users \ -H Content-Type: application/json \ -d {name: 张三, email: zhangsanexample.com}-X POST可以省略因为当使用-d时curl默认的请求方法就是 POST。-H用于添加请求头。发送表单数据application/x-www-form-urlencoded同样使用-d但数据格式是key1value1key2value2并且通常不需要显式指定Content-Typecurl会自动设置为application/x-www-form-urlencoded。curl -X POST https://api.example.com/login \ -d usernameadminpasswordsecret上传文件multipart/form-data当需要上传文件时比如网页上的文件选择框就需要使用-F--form参数。curl -X POST https://api.example.com/upload \ -F file/home/user/picture.jpg \ -F caption这是一张风景照符号告诉curl后面跟的是文件路径。-F会自动将Content-Type设置为multipart/form-data。核心原理-d和-F的本质区别在于对请求体的编码方式。-d是简单的键值对编码可以是JSON或URL编码而-F会将每个字段包括文件作为多部分multipart消息体的一部分进行编码每个部分都有自己的头部信息如文件名、内容类型。这就是为什么上传文件必须用-F。3.3 发送PUT、DELETE等请求-X对于RESTful APIPUT用于更新DELETE用于删除。使用-X--request参数可以指定任何HTTP方法。# 更新资源 curl -X PUT https://api.example.com/users/123 \ -H Content-Type: application/json \ -d {email: new_emailexample.com} # 删除资源 curl -X DELETE https://api.example.com/users/1234. 高级调试与性能洞察当基础功能无法定位问题时你需要更强大的工具。4.1 测量请求各阶段耗时-w 与 --trace-time性能优化时我们需要知道时间花在了哪里。-w--write-out参数可以输出格式化的信息其中包含一系列关于时间和性能的变量。一个非常实用的格式字符串是curl -w \n\n时间统计:\n DNS解析: %{time_namelookup} 秒\n 建立TCP连接: %{time_connect} 秒\n SSL握手如适用: %{time_appconnect} 秒\n 从开始到收到第一个字节TTFB: %{time_starttransfer} 秒\n 总耗时: %{time_total} 秒\n \ -o /dev/null -s https://www.example.com解释一下-o /dev/null 将输出内容丢弃到“黑洞”我们只关心时间数据。-s 静默模式不显示进度条或错误信息让输出更干净。%{time_namelookup} DNS域名解析耗时。%{time_connect} 建立TCP连接的耗时。%{time_appconnect} 建立SSL/TLS连接的耗时仅HTTPS。%{time_starttransfer} 从请求开始到收到服务器第一个响应字节的耗时TTFBTime To First Byte。这是衡量服务器响应速度的关键指标。%{time_total} 请求总耗时。通过这个输出你可以快速定位瓶颈。如果time_namelookup很大可能是DNS服务器慢如果time_connect很大可能是网络延迟高或服务器负载大如果time_starttransfer很大但time_connect很小那很可能是服务器应用本身处理慢。另一个有用的参数是--trace-time它会在-v输出的每一行前面加上时间戳让你看到请求和响应发生的精确时间点对于分析复杂的交互序列很有帮助。4.2 模拟特定客户端-A 与 -H有些服务器会根据User-Agent请求头返回不同的内容比如针对移动端和桌面端的页面。-A--user-agent可以让你伪装成任何客户端。curl -A Mozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X) AppleWebKit/605.1.15 https://example.com更通用的方法是使用-H直接设置任何请求头这在测试API鉴权、内容协商时必不可少。# 发送一个接受JSON格式的API请求 curl -H Accept: application/json https://api.example.com/data # 携带Bearer Token进行认证 curl -H Authorization: Bearer eyJhbGciOiJ... https://api.example.com/protected # 模拟来自特定来源的请求用于测试CORS curl -H Origin: http://localhost:3000 -v https://api.example.com/data4.3 处理Cookie-b 与 -cWeb应用离不开Cookie。curl可以发送和保存Cookie。-c file 将服务器返回的Cookie保存到指定文件。curl -c cookies.txt https://example.com/login -d useradminpass123-b file 从指定文件读取Cookie并随请求发送。也可以直接用字符串指定。# 从文件读取 curl -b cookies.txt https://example.com/dashboard # 直接指定Cookie字符串 curl -b sessionidabc123; usernameadmin https://example.com/dashboard这在进行需要登录会话的自动化测试时非常有用。你先用curl模拟登录并保存Cookie后续的请求都带上这个Cookie就能维持会话状态。5. 安全与稳定性保障在生产环境或处理重要数据时安全性和脚本的健壮性必须考虑。5.1 处理HTTPS与SSL证书在测试环境你可能会遇到自签名证书curl默认会拒绝连接并报错SSL certificate problem: self signed certificate。有几种处理方式-k或--insecure最不推荐但最方便。它告诉curl忽略所有SSL证书验证错误。仅在测试自己完全可控的、无关安全的内网服务时使用绝对不要在对公网或生产环境服务时使用。curl -k https://internal-test-server指定自定义CA证书推荐做法。如果你有自己的内部CA证书颁发机构可以将CA证书文件告诉curl。curl --cacert /path/to/company-ca.pem https://internal-server使用--cert和--key 如果服务端要求客户端证书认证双向TLS你需要提供自己的客户端证书和私钥。curl --cert /path/to/client.pem --key /path/to/client-key.pem https://secure-api.example.com5.2 控制超时与重试网络不稳定是常态你的脚本必须有容错能力。连接超时--connect-timeout 限制建立TCP连接的最长时间。如果服务器在指定秒数内没有响应SYN-ACK则放弃。curl --connect-timeout 10 https://example.com最大请求时间--max-time 限制整个curl操作的最长时间包括连接、传输等。这是防止脚本无限期挂起的最重要参数。curl --max-time 30 https://example.com/large-file失败重试--retry 当遇到瞬时的网络错误如连接超时、HTTP 5xx错误时自动重试。curl --retry 3 --retry-delay 5 https://example.com # 最多重试3次每次间隔5秒限制速度--limit-rate 避免curl占满带宽影响其他服务。curl --limit-rate 200K -O http://example.com/bigfile.iso # 将下载速度限制在每秒200KB经验之谈在编写用于监控或自动化部署的脚本时我几乎总是会加上--max-time和--retry参数。比如一个健康检查脚本curl -fsS --max-time 5 --retry 2 http://localhost:8080/health。-f--fail参数让curl在服务器返回HTTP错误状态码400时以非0状态退出这对于脚本判断成功失败非常关键。-sS是-s静默加上-S--show-error这样在失败时仍会显示错误信息但平时不输出无关内容。6. 实战串联一个完整的API测试与调试案例让我们把这些用法串起来模拟一个真实的场景你作为后端开发者需要测试一个刚开发完成的用户注册API。首先检查服务是否可达并查看基础信息curl -I http://localhost:8080/api/register如果返回404可能是路由不对如果返回405 Method Not Allowed说明这个端点不支持GET方法需要用POST。发送一个POST请求进行注册curl -X POST http://localhost:8080/api/register \ -H Content-Type: application/json \ -d {username: testuser, password: TestPass123, email: testexample.com} \ -v使用-v查看详细的请求和响应。假设服务器返回201 Created和一个包含用户ID的JSON体以及一个Set-Cookie头。假设注册成功并设置了会话Cookie我们保存这个Cookiecurl -X POST http://localhost:8080/api/register \ -H Content-Type: application/json \ -d {username: testuser2, password: TestPass123, email: test2example.com} \ -c session.cookie \ -s使用保存的Cookie测试需要登录才能访问的“获取用户信息”APIcurl -b session.cookie http://localhost:8080/api/user/profile -v观察请求是否自动带上了Cookie以及服务器是否返回了正确的用户信息。进行性能基准测试curl -w TTFB: %{time_starttransfer}s, 总时间: %{time_total}s\n \ -o /dev/null \ -b session.cookie \ http://localhost:8080/api/user/profile多次运行这个命令可以获取一个粗略的响应时间分布。模拟异常情况测试密码太短的错误。curl -X POST http://localhost:8080/api/register \ -H Content-Type: application/json \ -d {username: short, password: 123, email: ab.c} \ -f因为密码不符合规则服务器应该返回400 Bad Request。我们加了-f参数所以curl会以非0状态退出我们的脚本可以据此判断测试用例失败。通过这一套组合拳你几乎可以完成一个API接口的所有功能性测试而无需打开任何图形化工具。这种命令行驱动的测试方式尤其适合集成到CI/CD流水线中实现自动化测试。curl的强大远不止于此它还能处理FTP上传下载、支持代理、进行带宽测试等。但上面这十种用法覆盖了日常开发和运维工作中90%以上的场景。记住工具的价值不在于你知道它有多少参数而在于在遇到问题时你能立刻想起并组合使用那几个最合适的参数来快速解决问题。把curl当成你终端里的老朋友多用它多琢磨它你的工作效率一定会提升一个档次。