网上聊到 curl大部分教程默认你在 Linux 或者 macOS 上操作。实际上 Windows 10 1803 之后的系统已经内置了 curl.exe我日常调试接口、下载文件、写自动化脚本很多工作就是在 Windows 的 cmd 和 PowerShell 里完成的。这篇内容就是我在 Windows 下折腾 cURL 命令实战时积累的一套完整经验包含和 Linux 环境差异巨大的引号处理、curl 与 PowerShell 别名的冲突、高频参数的使用逻辑、本地回显服务实验、问题定位思路以及可以直接抄进批处理脚本的代码片段。适合两类人一类是从 Linux 切到 Windows 的开发者另一类是刚开始用命令行调试接口的测试或运维同学。1. Windows环境里的curl与Linux/macOS差异大这几点不搞清楚会白折腾1.1 系统自带curl.exe版本确认与路径Windows 10 1803 之后的系统已经默认带上了 curl.exeWindows 11 自然也不例外。打开 cmd直接输入curl.exe --version就能看到类似下面这种输出curl 8.x.x (x86_64-pc-win32) release-datelibcurl/8.x.x ...自带的位置一般在C:\Windows\System32\curl.exe。如果你输入where curl.exe能找到多个路径说明你可能另外装过比如用包管理器装的版本。很多时候系统自带的版本已经够用特别是较新的 Windows 版本里 curl 版本已经到 8.x一些实用参数比如后面的--json可以直接用。有个容易混乱的点在 PowerShell 里输入curl --version大概率不会得到 curl 的版本信息而是得到一段报错或者帮助信息。原因后面第 1.3 节会细说这里先记住一条铁律Windows 下凡是真想调用 curl就写curl.exe带上.exe后缀能避开一堆麻烦。如果确实需要更新 curl 版本可以用 Windows 的包管理器安装安装完把新版所在目录放到PATH前面即可。早期 Windows 10 自带的 curl 版本可能偏旧旧版本对--json、--retry-connrefused这类参数支持不完整遇到参数不识别时不要怀疑自己记错先升级再试。1.2 cmd的引号规则与bash不一样JSON参数尤其容易踩坑这是 Windows 下用 curl 最容易翻车的地方。在 Linux 的 bash 里单引号内的一切都是字面量所以很多人习惯写curl -d {name:bob,age:20} http://127.0.0.1:8000/api这段命令在 cmd 里运行是完全不对的。cmd 不把单引号当作字符串引用符单引号会被原样传给 curl服务器收到的 body 可能变成{name:bob,age:20}带着一对单引号服务端一解析 JSON 直接报错。在 cmd 里传 JSON 的常见做法有三种把 JSON 先写进文件再用-d payload.json读取curl.exe -H Content-Type: application/json -d payload.json http://127.0.0.1:8000/api切到 PowerShell用单引号包裹 JSONcurl.exe --json {name:bob,age:20} http://127.0.0.1:8000/api在 cmd 中用双引号加反斜杠转义curl.exe -d {\name\:\bob\,\age\:20} http://127.0.0.1:8000/api第三种方式在不同 Windows 版本上的表现并不完全一致转义层级一多就很容易翻车。我的建议是能用文件导入就用文件导入别在终端里手工敲复杂 JSON。这不仅是给 Windows 用户的建议即使 Linux 下JSON 越来越长时文件方式也远更可靠。1.3 PowerShell的curl别名坑它指向的是别的命令在 Windows PowerShell 5.1 里curl是Invoke-WebRequest的别名。你可以执行Get-Alias curl验证输出会告诉你它指向Invoke-WebRequest。这意味着你在 PowerShell 里写curl -s http://example.com看起来像在用 curl实际却是在用 PowerShell 自己的 cmdlet它的参数体系和 curl 完全不同比如-s会被理解为SessionVariable之类的参数报错也就顺理成章。PowerShell 7 开始默认不再把curl绑定为别名外部命令curl.exe可以被直接解析到但团队里总有人的环境还是 Windows PowerShell 5.1所以最稳妥的做法还是统一使用curl.exe。这个习惯一旦养成你在任何 Windows 机器的任何终端下都不会踩到这个坑。顺带一提PowerShell 里如果用Invoke-RestMethod调接口与 curl 的体验差别很大参数和作用完全不同不要指望两边可以一一对应。1.4 反斜杠路径与URL中的斜杠别搞混Windows 本地文件路径用反斜杠比如C:\temp\file.txt这没问题。但 URL 里的路径必须是正斜杠不能写http://127.0.0.1:8000\api\v1这一点大部分人都知道。真正容易忽略的是 cmd 对符号的处理。URL 带查询参数时会经常出现比如http://127.0.0.1:8000/api?namebobage20在 cmd 里如果没有用双引号把整个 URL 包起来会被当作命令分隔符cmd 会在处把命令断开接着把age20当作一条新命令去执行最终看到类似“age 不是内部或外部命令”的报错。所以凡是 URL 带查询参数一律加双引号curl.exe http://127.0.0.1:8000/api?namebobage20这个细节看起来很小实际工作中我见过不少同事在 Windows 下调试接口命令怎么改都报错最后发现就是查询串里的把命令拆断了。2. 把高频参数拆开讲透哪些必须记哪些可以临时查2.1 请求方法与 -X 的误区很多人一上来就用-X POST实际上 curl 在没有-X的情况下只要用了-d或--data请求方法会自动变成 POST。也就是说curl.exe -d namebob http://127.0.0.1:8000/api本身就是 POST 请求不需要再额外写-X POST。更进一步如果写了-I发送 HEAD 请求再用-X POST强制指定方法反而会得到一个 POST 而不是 HEAD这也是个常见坑。-X的真正用途是覆盖方法。比如用-X DELETE调删除接口或者在某些服务器对方法比较挑剔时显式指定。平时写 GET 请求什么都不加就是 GET写 POST用-d写 PUT 上传文件用-T。这样语义清晰也不容易出低级问题。还有一个和重定向相关的坑接口返回 302 跳转如果只写-L跟随重定向curl 默认在 301/302/303 场景下会把 POST 改成 GET。也就是说用 POST 提交登录表单服务器返回 302 让你跳转到首页curl 跟过去后请求方法已经变成 GET如果登录逻辑依赖 POST 跳转后携带的会话信息就会莫名其妙失效。解决办法是加--post301 --post302 --post303让 curl 在跟随这些重定向时保持 POST。2.2 数据提交-d、--data-urlencode、-H、--json-d是最常用的数据提交参数它会把数据以application/x-www-form-urlencoded格式发送。比如表单登录直接写curl.exe -d usernameadminpassword123456 http://127.0.0.1:8000/login当数据里包含中文、空格、特殊符号时-d不会自动替你编码你需要自己把内容转成 URL 编码或者用--data-urlencodecurl.exe --data-urlencode comment今天天气不错 --data-urlencode page1 http://127.0.0.1:8000/api--data-urlencode会自动把今天天气不错编码成%E4%BB%8A%E5%A4%A9...这样的形式比手工用 Python 或在线工具转换方便得多。提交 JSON 时需要设置Content-Type: application/json同时用-d指定 JSON 字符串或文件curl.exe -H Content-Type: application/json -d payload.json http://127.0.0.1:8000/apicurl 7.82.0 之后推荐直接用--json参数它会自动设置Content-Type: application/json同时支持字符串和文件curl.exe --json {name:bob,age:20} http://127.0.0.1:8000/api注意-d file里的表示“读取文件内容”而如果数据本身要以开头需要写成-d literal这种形式。这是个小门道碰到特殊符号时才能用上。2.3 输出控制-o、-O、-sS、-i、-I、-L、-v、-w整理了一张表基本覆盖日常使用频率最高的输出参数参数作用典型场景-o 文件名把响应内容保存到指定文件下载文件并自定义文件名-O按 URL 路径最后一段作为文件名保存未指定文件名时用远端默认名-s静默模式不显示进度条和错误信息脚本里不希望有额外输出-S与-s一起用出错时仍显示错误日志采集时兼顾清晰和安静-i在响应正文前输出响应头快速查看状态码和响应头-I发送 HEAD 请求只显示响应头检查资源是否存在、版本号等-L自动跟随重定向处理 301/302-v输出完整通信过程排查问题时第一步-w输出自定义格式化信息统计耗时、状态码-o NUL在 Windows 下是把内容丢弃到空设备等价于 Linux 下的-o /dev/null。比如只想看接口状态码不关心响应体就可以这样curl.exe -sS -o NUL -w %{http_code} http://127.0.0.1:8000/health-O虽然方便但如果 URL 路径最后一段长得像download?id123保存下来的文件名不一定理想所以脚本里我更倾向于显式-o让文件名叫什么是确定的。2.4 文件传输-F与-T的边界-F用于模拟浏览器的表单提交生成的是multipart/form-data格式既可以传普通字段也可以传文件。基本写法curl.exe -F usernameadmin -F avatarC:\temp\avatar.png http://127.0.0.1:8000/upload需要给上传文件重命名或者指定 MIME 类型可以这样扩展curl.exe -F avatarC:\temp\avatar.png;filenamehead.png;typeimage/png http://127.0.0.1:8000/upload-T则是以 PUT 方式上传原始文件语义是把本地文件内容直接放到远端指定的路径上和浏览器表单上传完全不同。它天然默认就是 PUT 方法不需要额外加-X PUT。实际使用curl.exe -T C:\temp\backup.zip http://127.0.0.1:8000/files/backup.zip-F和-T的选择标准就一句话如果你在模拟“网页里的表单提交”用-F如果你在做“客户端和服务端之间的文件传输”用-T。2.5 Cookie 会话-b、-c、-j调需要登录的接口常见做法是先调登录接口把 Cookie 存下来后续请求再带上。两个关键参数-c cookies.txt把服务器通过Set-Cookie下发的 Cookie 写入文件。-b cookies.txt从文件读取 Cookie 并携带在请求中。具体流程curl.exe -c cookies.txt -d usernameadminpassword123456 http://127.0.0.1:8000/login curl.exe -b cookies.txt http://127.0.0.1:8000/userinfoCookie 文件的格式是 Netscape 格式每行一个字段可以直接用记事本打开看里面能看到域名、路径、过期时间、Cookie 名称和值。这里要注意-j参数它的作用是读取 Cookie 文件时忽略会话类 Cookie没有过期时间的只加载持久化 Cookie。如果会话本身依赖一个临时session_id加-j反而会让登录状态丢失。我在实际使用中很少加-j除非明确知道会话里混了哪些不用带的临时 Cookie。3. 本地搭一个回显服务把每个参数的命令都跑一遍3.1 一个极简的HTTP回显服务脚本理解 curl 参数最有效的方式是让它把请求原原本本发到一个你能看到所有细节的服务上。公网接口行为不可控不如在本地起一个“回显服务”谁请求它它就把请求的方法、路径、请求头、请求体原样打印成 JSON 返回。用 Python 标准库就能实现不需要装任何第三方包。新建一个文件echo_server.py内容如下import json from http.server import BaseHTTPRequestHandler, HTTPServer class EchoHandler(BaseHTTPRequestHandler): def _reply(self): length int(self.headers.get(Content-Length) or 0) body self.rfile.read(length) if length else b result { method: self.command, path: self.path, headers: dict(self.headers.items()), body: body.decode(utf-8, replace), } data json.dumps(result, indent2, ensure_asciiFalse).encode(utf-8) self.send_response(200) self.send_header(Set-Cookie, session_idabc123; Path/) self.send_header(Content-Type, application/json; charsetutf-8) self.send_header(Content-Length, str(len(data))) self.end_headers() self.wfile.write(data) do_GET _reply do_POST _reply do_PUT _reply HTTPServer((127.0.0.1, 8000), EchoHandler).serve_forever()在终端执行python echo_server.py看到类似Serving HTTP on 127.0.0.1 port 8000的输出服务就跑起来了。第一次运行时 Windows 防火墙可能会弹窗如果只是本机调试直接允许专用网络访问即可。保持这个窗口别关另开一个终端窗口后面的所有演示都在这台“回显服务”上做。3.2 GET请求实操-v输出每一行怎么看先跑一个最简单的 GET 请求并打开-vcurl.exe -v http://127.0.0.1:8000/hello?namebob-v的输出会分成几个阶段。开头的Trying 127.0.0.1:8000...表示正在建立 TCP 连接Connected to 127.0.0.1表示连接成功接着是请求头发送阶段 GET /hello?namebob HTTP/1.1开头的部分是你发出的内容然后Received HTTP code 200 from proxy这种行在不同环境可能长成* Mark bundle as not supporting multiuse不必纠结真正要关注的是 HTTP/1.0 200 OK这表示服务器返回了状态码 200。回显服务返回的 JSON 里可以看到它收到的请求方法确实是GET路径是/hello?namebob请求头里还有Host: 127.0.0.1:8000。这样的好处是你可以立刻对照 curl 文档理解每个参数干了什么因为回显服务把你实际发出的东西毫无保留地展示出来了。如果要保留网络日志可以用--trace-ascii trace.log把整个通信过程写入文件curl.exe --trace-ascii trace.log http://127.0.0.1:8000/hello这对排查加了加密协议后的问题特别有用比-v输出更细包含每个字节的十六进制和文本对照。3.3 POST表单与JSON请求实操三种常用方式对照先试普通表单提交curl.exe -d namebobage20 http://127.0.0.1:8000/api回显服务返回的 JSON 里method会变成POSTbody是namebobage20。注意这里没有-X POSTcurl 自动根据-d把请求方法改成了 POST。再试中文数据curl.exe --data-urlencode name张三 --data-urlencode city上海 http://127.0.0.1:8000/api回显的 body 是 URL 编码后的内容形如name%E5%BC%A0%E4%B8%89city%E4%B8%8A%E6%B5%B7。服务端收回来后进行 URL decode自然能得到原始中文。如果你直接用-d name张三curl 会按原样发过去遇到不兼容的服务器就会变成乱码所以有中文的场景优先用--data-urlencode。再试 JSON。在 PowerShell 下可以直接写curl.exe --json {name:bob,age:20} http://127.0.0.1:8000/api回显结果中headers里的content-type是application/jsonbody是完整的 JSON 字符串。整个过程一键完成连手写Content-Type都省了。如果你在 cmd 下操作不方便用单引号把 JSON 写入payload.json文件然后curl.exe -H Content-Type: application/json -d payload.json http://127.0.0.1:8000/api两种方式效果一致文件方式更适合复杂 JSON。3.4 文件上传与下载-F/-O/-C - 的组合玩法先在本地创建一个测试文件比如demo.txt里面写点内容hello curl然后试-F上传curl.exe -F fieldvalue -F filedemo.txt;filenameupload.txt;typetext/plain http://127.0.0.1:8000/upload回显服务返回的 body 会是一个很长的multipart/form-data内容里面能看到Content-Disposition: form-data; namefile; filenameupload.txt以及文件内容。这就是浏览器提交文件时实际发送的格式。下载场景可以单独开一个静态文件服务。在放有测试文件的目录下执行python -m http.server 8001然后curl.exe -o downloaded.txt http://127.0.0.1:8001/demo.txt-o指定了本地文件名非常清晰。要验证断点续传可以先下载一部分后中断再用-C -续传curl.exe -C - -o downloaded.txt http://127.0.0.1:8001/demo.txt-C -里的-表示“自动从已有文件的大小作为起始位置”。续传的前提是服务器支持Range请求头。如果服务器不支持curl 会提示类似HTTP server doesnt seem to support byte ranges的内容这时候只能重新下载。用回显服务可以直观看到-C -发出的请求头里带着Range: bytesxxx这一步至少能确认客户端确实在按断点续传的逻辑工作。3.5 Cookie保持登录用-c/b模拟会话状态因为回显服务每次响应都会设置session_idabc123; Path/所以可以直接演示 Cookie 的存取。第一次请求把 Cookie 保存到文件curl.exe -c cookies.txt http://127.0.0.1:8000/api用文本编辑器打开cookies.txt能看到类似这样的行127.0.0.1 FALSE / FALSE 0 session_id abc123这就是 Netscape Cookie 格式字段依次是域名、是否包含子域、路径、是否需要 HTTPS、过期时间、Cookie 名、Cookie 值。第二次请求带上 Cookie 文件curl.exe -b cookies.txt http://127.0.0.1:8000/api回显 JSON 里headers中会多出cookie: session_idabc123。这模拟的就是“登录后保持会话”的基本链路登录接口返回的会话凭证被保存后续业务请求自动携带。如果会话凭证没有写入文件而是写在内存里那关掉终端就只能重新登录了。4. 请求结果不对时我是按这套流程定位问题的4.1 先看-v输出按网络阶段逐步排查拿到一个诡异结果第一件事永远是用-v重新跑一遍而不是猜参数。-v的输出是有顺序的按阶段对应不同问题-v输出关键行所处阶段常见问题Trying 127.0.0.1:8000...TCP 连接服务没启动、端口错、防火墙拦截Connected to 127.0.0.1TCP 连接成功无SSL connection using ...TLS 握手证书、加密套件不匹配 GET /path HTTP/1.1请求发送查看请求行是否符合预期 HTTP/1.1 200 OK收到响应头状态码不是预期响应体内容接收阶段乱码、截断、压缩未解比如你请求http://127.0.0.1:8000/health如果卡在Trying后长期没有Connected就别继续看请求参数了先去看服务到底有没有跑起来、端口有没有监听。Windows 下可以用netstat -ano | findstr :8000看输出里是否有LISTENING状态。没有 LISTENING说明服务没起来或者端口号不对。这一步能过滤掉大量无关干扰。4.2 证书验证失败CURLE_PEER_FAILED_VERIFICATION访问https://的接口时报错形如curl: (60) SSL certificate problem: self-signed certificate常见原因有三类服务器用的是自签证书服务器证书过期或域名不匹配本机系统时间错误导致证书有效期校验失败。这类场景多见于访问公司内网、本地测试环境或者某些老旧设备的管理接口。临时验证可以用-k跳过证书校验但脚本化和自动化场景里不建议写死-k它会关闭 TLS 的身份验证能力等于裸奔。更好的做法是拿到服务端的证书文件用--cacert指定curl.exe --cacert server-ca.pem https://api.example.com/health如果你是自签服务器还可以考虑把根证书导入 Windows 的受信任根证书存储。导入后curl 大概率就能直接通过校验不需要每次附加参数。注意证书问题不影响本机回显服务因为 127.0.0.1 默认走 HTTP不涉及 TLS。4.3 Windows防火墙或安全软件拦截还有一类问题请求目标没问题、服务也确实启动了但 curl 就是连不上。表现通常是连接超时或者报Connection refused。Connection refused 说明目标端口没有进程监听而超时可能意味着防火墙把包丢弃了。在 Windows 上排查时除了看服务日志还要考虑安全软件。某些安全软件会对curl.exe这种命令行网络工具做行为拦截尤其是第一次运行时弹窗请求网络权限没允许的话后续请求会一直被拦。判断方法很简单换一个网络请求工具试试比如用浏览器访问同一个地址如果浏览器正常而 curl 异常大概率是安全软件拦了 curl 的进程。另外注意回环地址127.0.0.1一般不会被防火墙拦但如果你请求的是局域网内另一台机器的服务Windows 防火墙可能会弹窗询问是否允许通信没有允许就会不通。这种“本机能通、跨机器不通”的现象优先检查双方的防火墙规则。4.4 响应内容与预期不符乱码、压缩、命令拆分响应能拿到但内容和预期不同这是最常见的第二类问题。先是乱码。curl 本身不会做字符集转换它只是原样搬运字节。如果服务端返回的是 GBK 编码而终端默认按 UTF-8 显示中文就会乱码。解决办法不在 curl而在显示端要么把响应保存到文件后用支持对应编码的编辑器打开要么让服务端改成返回 UTF-8。再是内容看起来像乱码二进制实际可能是压缩响应。服务器返回了Content-Encoding: gzipcurl 没有自动解压就会显示一堆乱码。这种情况加--compressedcurl 会自动发送带Accept-Encoding的请求并对返回的压缩内容自动解压。如果你不希望服务器压缩也可以用-H Accept-Encoding: identity明确要求不压缩。还有一种低级但常见的命令拆分。前面提到过URL 里的没加引号在 cmd 里会被当成命令分隔符。实际报错一般长这样age 不是内部或外部命令也不是可运行的程序或批处理文件。看到这个报错先回头检查 URL 是不是没包双引号。这类问题往往发生在切换终端环境后同一个命令在 Linux shell 下正常粘到 cmd 里就断成两截。5. 把curl写进Windows脚本与日常自动化几个可直接抄的片段5.1 cmd批处理中检查HTTP状态码并处理错误在.bat脚本里使用 curl最常用的需求是根据 HTTP 状态码决定后续流程。先看一个完整示例echo off setlocal set URLhttp://127.0.0.1:8000/health curl.exe -sS -o nul -w %%{http_code} %URL% code.txt set /p HTTP_CODEcode.txt echo HTTP_CODE%HTTP_CODE% if %HTTP_CODE%200 ( echo 接口正常 ) else ( echo 接口异常退出 exit /b 1 )这里有两个细节值得强调。第一-o nul把响应体丢弃-w %{http_code}只输出状态码。状态码被重定向到code.txt再用set /p HTTP_CODEcode.txt读回来。为什么不直接用%ERRORLEVEL%判断因为 curl 的退出码表示的是传输层是否成功比如服务器返回 404 或 500curl 退出码仍然是 0只有请求彻底失败连接不上、超时才有非零退出码。所以想判断 HTTP 语义必须把状态码拿出来。第二批处理文件里%的转义。上面代码写的是%%{http_code}两个%%最终会被 cmd 解释成一个%传到 curl 那边就是%{http_code}。如果你在 cmd 窗口里直接敲命令只写一个%即可写进.bat文件必须写两个否则变量解析会出错。这个坑即使老手也容易一时忘掉。5.2 PowerShell脚本中调用curl.exePowerShell 里调用外部 exe习惯上使用调用运算符方便同时拿到退出码和输出。按下 trap$url http://127.0.0.1:8000/health $code curl.exe -sS -o response.json -w %{http_code} $url if ($LASTEXITCODE -ne 0) { Write-Host curl 调用失败退出码: $LASTEXITCODE exit 1 } if ($code -ne 200) { Write-Host 接口返回异常状态: $code exit 1 } $data Get-Content response.json -Raw | ConvertFrom-Json$LASTEXITCODE是 PowerShell 里保存上次外部程序退出码的自动变量和 cmd 的%ERRORLEVEL%对应。这里我把-w %{http_code}用单引号包起来PowerShell 不会把%{http_code}解析成变量原样传给 curl省去转义烦恼。使用ConvertFrom-Json时特别注意curl 下载的文件如果带 UTF-8 BOMGet-Content -Raw能正常处理如果不带 BOM 且包含中文可能需要用-Encoding UTF8指定读取编码避免中文解析成乱码。5.3 接口冒烟测试与耗时统计把一组接口地址放进数组循环请求任何一个非 200 就失败退出这个模式非常适合部署后的冒烟验证。$urls ( http://127.0.0.1:8000/health, http://127.0.0.1:8000/api/v1/users, http://127.0.0.1:8000/api/v1/orders ) foreach ($u in $urls) { $code curl.exe -sS -o NUL -w %{http_code} $u if ($code -eq 200) { Write-Host $u OK } else { Write-Host $u FAIL: $code exit 1 } }如果还想看每个接口的耗时可以用-w把多个时间字段一起输出curl.exe -sS -o NUL -w 连接:%{time_connect}s 总耗时:%{time_total}sn http://127.0.0.1:8000/apitime_connect是 TCP 连接建立耗时time_total是请求从开始到结束的总耗时。在 Windows 终端里想要换行显示多个字段可以像上面这样在双引号里写反引号 n也可以配合echo换行。这个输出对粗略判断接口性能非常有用不用开任何图形化工具。5.4 组合参数处理不稳定网络重试与断点续传实际运行中最常见的问题不是接口逻辑错而是网络抖动导致请求失败。curl 自带了比较完善的重试机制curl.exe --retry 3 --retry-delay 2 --retry-connrefused --connect-timeout 5 -o data.txt http://127.0.0.1:8001/data.txt参数含义--retry 3表示最多重试 3 次--retry-delay 2表示重试前等待 2 秒--retry-connrefused让连接被拒绝时也参与重试--connect-timeout 5表示 TCP 连接超时 5 秒直接放弃。组合起来用在自动化下载场景里能大幅降低临时故障的影响。如果要下载大文件还可以把重试和断点续传合并curl.exe --retry 3 --retry-delay 2 -C - -o bigfile.zip http://127.0.0.1:8001/bigfile.zip这样当下载中途断掉时再次执行会从本地已有文件大小处继续请求剩余部分而不是重新下整个文件。我自己在 Windows 上处理定时任务下载时这一条命令基本没再出过“下载了一半就全丢”的问题。最后补一个我自己的使用习惯凡是涉及关键请求我都不直接在终端里敲长命令而是先写成脚本文件再执行。Windows 终端的引号、编码、%转义规则太多手敲出错概率高尤其在 cmd 和 PowerShell 之间来回切换时。遇到异常先跑一次-v把完整输出留档确认问题到底在连接阶段、证书阶段、还是业务逻辑阶段再对症下药。这套流程走熟之后curl 在 Windows 下基本不会给你拖后腿。
网上聊到 curl大部分教程默认你在 Linux 或者 macOS 上操作。实际上 Windows 10 1803 之后的系统已经内置了 curl.exe我日常调试接口、下载文件、写自动化脚本很多工作就是在 Windows 的 cmd 和 PowerShell 里完成的。这篇内容就是我在 Windows 下折腾 cURL 命令实战时积累的一套完整经验包含和 Linux 环境差异巨大的引号处理、curl 与 PowerShell 别名的冲突、高频参数的使用逻辑、本地回显服务实验、问题定位思路以及可以直接抄进批处理脚本的代码片段。适合两类人一类是从 Linux 切到 Windows 的开发者另一类是刚开始用命令行调试接口的测试或运维同学。1. Windows环境里的curl与Linux/macOS差异大这几点不搞清楚会白折腾1.1 系统自带curl.exe版本确认与路径Windows 10 1803 之后的系统已经默认带上了 curl.exeWindows 11 自然也不例外。打开 cmd直接输入curl.exe --version就能看到类似下面这种输出curl 8.x.x (x86_64-pc-win32) release-datelibcurl/8.x.x ...自带的位置一般在C:\Windows\System32\curl.exe。如果你输入where curl.exe能找到多个路径说明你可能另外装过比如用包管理器装的版本。很多时候系统自带的版本已经够用特别是较新的 Windows 版本里 curl 版本已经到 8.x一些实用参数比如后面的--json可以直接用。有个容易混乱的点在 PowerShell 里输入curl --version大概率不会得到 curl 的版本信息而是得到一段报错或者帮助信息。原因后面第 1.3 节会细说这里先记住一条铁律Windows 下凡是真想调用 curl就写curl.exe带上.exe后缀能避开一堆麻烦。如果确实需要更新 curl 版本可以用 Windows 的包管理器安装安装完把新版所在目录放到PATH前面即可。早期 Windows 10 自带的 curl 版本可能偏旧旧版本对--json、--retry-connrefused这类参数支持不完整遇到参数不识别时不要怀疑自己记错先升级再试。1.2 cmd的引号规则与bash不一样JSON参数尤其容易踩坑这是 Windows 下用 curl 最容易翻车的地方。在 Linux 的 bash 里单引号内的一切都是字面量所以很多人习惯写curl -d {name:bob,age:20} http://127.0.0.1:8000/api这段命令在 cmd 里运行是完全不对的。cmd 不把单引号当作字符串引用符单引号会被原样传给 curl服务器收到的 body 可能变成{name:bob,age:20}带着一对单引号服务端一解析 JSON 直接报错。在 cmd 里传 JSON 的常见做法有三种把 JSON 先写进文件再用-d payload.json读取curl.exe -H Content-Type: application/json -d payload.json http://127.0.0.1:8000/api切到 PowerShell用单引号包裹 JSONcurl.exe --json {name:bob,age:20} http://127.0.0.1:8000/api在 cmd 中用双引号加反斜杠转义curl.exe -d {\name\:\bob\,\age\:20} http://127.0.0.1:8000/api第三种方式在不同 Windows 版本上的表现并不完全一致转义层级一多就很容易翻车。我的建议是能用文件导入就用文件导入别在终端里手工敲复杂 JSON。这不仅是给 Windows 用户的建议即使 Linux 下JSON 越来越长时文件方式也远更可靠。1.3 PowerShell的curl别名坑它指向的是别的命令在 Windows PowerShell 5.1 里curl是Invoke-WebRequest的别名。你可以执行Get-Alias curl验证输出会告诉你它指向Invoke-WebRequest。这意味着你在 PowerShell 里写curl -s http://example.com看起来像在用 curl实际却是在用 PowerShell 自己的 cmdlet它的参数体系和 curl 完全不同比如-s会被理解为SessionVariable之类的参数报错也就顺理成章。PowerShell 7 开始默认不再把curl绑定为别名外部命令curl.exe可以被直接解析到但团队里总有人的环境还是 Windows PowerShell 5.1所以最稳妥的做法还是统一使用curl.exe。这个习惯一旦养成你在任何 Windows 机器的任何终端下都不会踩到这个坑。顺带一提PowerShell 里如果用Invoke-RestMethod调接口与 curl 的体验差别很大参数和作用完全不同不要指望两边可以一一对应。1.4 反斜杠路径与URL中的斜杠别搞混Windows 本地文件路径用反斜杠比如C:\temp\file.txt这没问题。但 URL 里的路径必须是正斜杠不能写http://127.0.0.1:8000\api\v1这一点大部分人都知道。真正容易忽略的是 cmd 对符号的处理。URL 带查询参数时会经常出现比如http://127.0.0.1:8000/api?namebobage20在 cmd 里如果没有用双引号把整个 URL 包起来会被当作命令分隔符cmd 会在处把命令断开接着把age20当作一条新命令去执行最终看到类似“age 不是内部或外部命令”的报错。所以凡是 URL 带查询参数一律加双引号curl.exe http://127.0.0.1:8000/api?namebobage20这个细节看起来很小实际工作中我见过不少同事在 Windows 下调试接口命令怎么改都报错最后发现就是查询串里的把命令拆断了。2. 把高频参数拆开讲透哪些必须记哪些可以临时查2.1 请求方法与 -X 的误区很多人一上来就用-X POST实际上 curl 在没有-X的情况下只要用了-d或--data请求方法会自动变成 POST。也就是说curl.exe -d namebob http://127.0.0.1:8000/api本身就是 POST 请求不需要再额外写-X POST。更进一步如果写了-I发送 HEAD 请求再用-X POST强制指定方法反而会得到一个 POST 而不是 HEAD这也是个常见坑。-X的真正用途是覆盖方法。比如用-X DELETE调删除接口或者在某些服务器对方法比较挑剔时显式指定。平时写 GET 请求什么都不加就是 GET写 POST用-d写 PUT 上传文件用-T。这样语义清晰也不容易出低级问题。还有一个和重定向相关的坑接口返回 302 跳转如果只写-L跟随重定向curl 默认在 301/302/303 场景下会把 POST 改成 GET。也就是说用 POST 提交登录表单服务器返回 302 让你跳转到首页curl 跟过去后请求方法已经变成 GET如果登录逻辑依赖 POST 跳转后携带的会话信息就会莫名其妙失效。解决办法是加--post301 --post302 --post303让 curl 在跟随这些重定向时保持 POST。2.2 数据提交-d、--data-urlencode、-H、--json-d是最常用的数据提交参数它会把数据以application/x-www-form-urlencoded格式发送。比如表单登录直接写curl.exe -d usernameadminpassword123456 http://127.0.0.1:8000/login当数据里包含中文、空格、特殊符号时-d不会自动替你编码你需要自己把内容转成 URL 编码或者用--data-urlencodecurl.exe --data-urlencode comment今天天气不错 --data-urlencode page1 http://127.0.0.1:8000/api--data-urlencode会自动把今天天气不错编码成%E4%BB%8A%E5%A4%A9...这样的形式比手工用 Python 或在线工具转换方便得多。提交 JSON 时需要设置Content-Type: application/json同时用-d指定 JSON 字符串或文件curl.exe -H Content-Type: application/json -d payload.json http://127.0.0.1:8000/apicurl 7.82.0 之后推荐直接用--json参数它会自动设置Content-Type: application/json同时支持字符串和文件curl.exe --json {name:bob,age:20} http://127.0.0.1:8000/api注意-d file里的表示“读取文件内容”而如果数据本身要以开头需要写成-d literal这种形式。这是个小门道碰到特殊符号时才能用上。2.3 输出控制-o、-O、-sS、-i、-I、-L、-v、-w整理了一张表基本覆盖日常使用频率最高的输出参数参数作用典型场景-o 文件名把响应内容保存到指定文件下载文件并自定义文件名-O按 URL 路径最后一段作为文件名保存未指定文件名时用远端默认名-s静默模式不显示进度条和错误信息脚本里不希望有额外输出-S与-s一起用出错时仍显示错误日志采集时兼顾清晰和安静-i在响应正文前输出响应头快速查看状态码和响应头-I发送 HEAD 请求只显示响应头检查资源是否存在、版本号等-L自动跟随重定向处理 301/302-v输出完整通信过程排查问题时第一步-w输出自定义格式化信息统计耗时、状态码-o NUL在 Windows 下是把内容丢弃到空设备等价于 Linux 下的-o /dev/null。比如只想看接口状态码不关心响应体就可以这样curl.exe -sS -o NUL -w %{http_code} http://127.0.0.1:8000/health-O虽然方便但如果 URL 路径最后一段长得像download?id123保存下来的文件名不一定理想所以脚本里我更倾向于显式-o让文件名叫什么是确定的。2.4 文件传输-F与-T的边界-F用于模拟浏览器的表单提交生成的是multipart/form-data格式既可以传普通字段也可以传文件。基本写法curl.exe -F usernameadmin -F avatarC:\temp\avatar.png http://127.0.0.1:8000/upload需要给上传文件重命名或者指定 MIME 类型可以这样扩展curl.exe -F avatarC:\temp\avatar.png;filenamehead.png;typeimage/png http://127.0.0.1:8000/upload-T则是以 PUT 方式上传原始文件语义是把本地文件内容直接放到远端指定的路径上和浏览器表单上传完全不同。它天然默认就是 PUT 方法不需要额外加-X PUT。实际使用curl.exe -T C:\temp\backup.zip http://127.0.0.1:8000/files/backup.zip-F和-T的选择标准就一句话如果你在模拟“网页里的表单提交”用-F如果你在做“客户端和服务端之间的文件传输”用-T。2.5 Cookie 会话-b、-c、-j调需要登录的接口常见做法是先调登录接口把 Cookie 存下来后续请求再带上。两个关键参数-c cookies.txt把服务器通过Set-Cookie下发的 Cookie 写入文件。-b cookies.txt从文件读取 Cookie 并携带在请求中。具体流程curl.exe -c cookies.txt -d usernameadminpassword123456 http://127.0.0.1:8000/login curl.exe -b cookies.txt http://127.0.0.1:8000/userinfoCookie 文件的格式是 Netscape 格式每行一个字段可以直接用记事本打开看里面能看到域名、路径、过期时间、Cookie 名称和值。这里要注意-j参数它的作用是读取 Cookie 文件时忽略会话类 Cookie没有过期时间的只加载持久化 Cookie。如果会话本身依赖一个临时session_id加-j反而会让登录状态丢失。我在实际使用中很少加-j除非明确知道会话里混了哪些不用带的临时 Cookie。3. 本地搭一个回显服务把每个参数的命令都跑一遍3.1 一个极简的HTTP回显服务脚本理解 curl 参数最有效的方式是让它把请求原原本本发到一个你能看到所有细节的服务上。公网接口行为不可控不如在本地起一个“回显服务”谁请求它它就把请求的方法、路径、请求头、请求体原样打印成 JSON 返回。用 Python 标准库就能实现不需要装任何第三方包。新建一个文件echo_server.py内容如下import json from http.server import BaseHTTPRequestHandler, HTTPServer class EchoHandler(BaseHTTPRequestHandler): def _reply(self): length int(self.headers.get(Content-Length) or 0) body self.rfile.read(length) if length else b result { method: self.command, path: self.path, headers: dict(self.headers.items()), body: body.decode(utf-8, replace), } data json.dumps(result, indent2, ensure_asciiFalse).encode(utf-8) self.send_response(200) self.send_header(Set-Cookie, session_idabc123; Path/) self.send_header(Content-Type, application/json; charsetutf-8) self.send_header(Content-Length, str(len(data))) self.end_headers() self.wfile.write(data) do_GET _reply do_POST _reply do_PUT _reply HTTPServer((127.0.0.1, 8000), EchoHandler).serve_forever()在终端执行python echo_server.py看到类似Serving HTTP on 127.0.0.1 port 8000的输出服务就跑起来了。第一次运行时 Windows 防火墙可能会弹窗如果只是本机调试直接允许专用网络访问即可。保持这个窗口别关另开一个终端窗口后面的所有演示都在这台“回显服务”上做。3.2 GET请求实操-v输出每一行怎么看先跑一个最简单的 GET 请求并打开-vcurl.exe -v http://127.0.0.1:8000/hello?namebob-v的输出会分成几个阶段。开头的Trying 127.0.0.1:8000...表示正在建立 TCP 连接Connected to 127.0.0.1表示连接成功接着是请求头发送阶段 GET /hello?namebob HTTP/1.1开头的部分是你发出的内容然后Received HTTP code 200 from proxy这种行在不同环境可能长成* Mark bundle as not supporting multiuse不必纠结真正要关注的是 HTTP/1.0 200 OK这表示服务器返回了状态码 200。回显服务返回的 JSON 里可以看到它收到的请求方法确实是GET路径是/hello?namebob请求头里还有Host: 127.0.0.1:8000。这样的好处是你可以立刻对照 curl 文档理解每个参数干了什么因为回显服务把你实际发出的东西毫无保留地展示出来了。如果要保留网络日志可以用--trace-ascii trace.log把整个通信过程写入文件curl.exe --trace-ascii trace.log http://127.0.0.1:8000/hello这对排查加了加密协议后的问题特别有用比-v输出更细包含每个字节的十六进制和文本对照。3.3 POST表单与JSON请求实操三种常用方式对照先试普通表单提交curl.exe -d namebobage20 http://127.0.0.1:8000/api回显服务返回的 JSON 里method会变成POSTbody是namebobage20。注意这里没有-X POSTcurl 自动根据-d把请求方法改成了 POST。再试中文数据curl.exe --data-urlencode name张三 --data-urlencode city上海 http://127.0.0.1:8000/api回显的 body 是 URL 编码后的内容形如name%E5%BC%A0%E4%B8%89city%E4%B8%8A%E6%B5%B7。服务端收回来后进行 URL decode自然能得到原始中文。如果你直接用-d name张三curl 会按原样发过去遇到不兼容的服务器就会变成乱码所以有中文的场景优先用--data-urlencode。再试 JSON。在 PowerShell 下可以直接写curl.exe --json {name:bob,age:20} http://127.0.0.1:8000/api回显结果中headers里的content-type是application/jsonbody是完整的 JSON 字符串。整个过程一键完成连手写Content-Type都省了。如果你在 cmd 下操作不方便用单引号把 JSON 写入payload.json文件然后curl.exe -H Content-Type: application/json -d payload.json http://127.0.0.1:8000/api两种方式效果一致文件方式更适合复杂 JSON。3.4 文件上传与下载-F/-O/-C - 的组合玩法先在本地创建一个测试文件比如demo.txt里面写点内容hello curl然后试-F上传curl.exe -F fieldvalue -F filedemo.txt;filenameupload.txt;typetext/plain http://127.0.0.1:8000/upload回显服务返回的 body 会是一个很长的multipart/form-data内容里面能看到Content-Disposition: form-data; namefile; filenameupload.txt以及文件内容。这就是浏览器提交文件时实际发送的格式。下载场景可以单独开一个静态文件服务。在放有测试文件的目录下执行python -m http.server 8001然后curl.exe -o downloaded.txt http://127.0.0.1:8001/demo.txt-o指定了本地文件名非常清晰。要验证断点续传可以先下载一部分后中断再用-C -续传curl.exe -C - -o downloaded.txt http://127.0.0.1:8001/demo.txt-C -里的-表示“自动从已有文件的大小作为起始位置”。续传的前提是服务器支持Range请求头。如果服务器不支持curl 会提示类似HTTP server doesnt seem to support byte ranges的内容这时候只能重新下载。用回显服务可以直观看到-C -发出的请求头里带着Range: bytesxxx这一步至少能确认客户端确实在按断点续传的逻辑工作。3.5 Cookie保持登录用-c/b模拟会话状态因为回显服务每次响应都会设置session_idabc123; Path/所以可以直接演示 Cookie 的存取。第一次请求把 Cookie 保存到文件curl.exe -c cookies.txt http://127.0.0.1:8000/api用文本编辑器打开cookies.txt能看到类似这样的行127.0.0.1 FALSE / FALSE 0 session_id abc123这就是 Netscape Cookie 格式字段依次是域名、是否包含子域、路径、是否需要 HTTPS、过期时间、Cookie 名、Cookie 值。第二次请求带上 Cookie 文件curl.exe -b cookies.txt http://127.0.0.1:8000/api回显 JSON 里headers中会多出cookie: session_idabc123。这模拟的就是“登录后保持会话”的基本链路登录接口返回的会话凭证被保存后续业务请求自动携带。如果会话凭证没有写入文件而是写在内存里那关掉终端就只能重新登录了。4. 请求结果不对时我是按这套流程定位问题的4.1 先看-v输出按网络阶段逐步排查拿到一个诡异结果第一件事永远是用-v重新跑一遍而不是猜参数。-v的输出是有顺序的按阶段对应不同问题-v输出关键行所处阶段常见问题Trying 127.0.0.1:8000...TCP 连接服务没启动、端口错、防火墙拦截Connected to 127.0.0.1TCP 连接成功无SSL connection using ...TLS 握手证书、加密套件不匹配 GET /path HTTP/1.1请求发送查看请求行是否符合预期 HTTP/1.1 200 OK收到响应头状态码不是预期响应体内容接收阶段乱码、截断、压缩未解比如你请求http://127.0.0.1:8000/health如果卡在Trying后长期没有Connected就别继续看请求参数了先去看服务到底有没有跑起来、端口有没有监听。Windows 下可以用netstat -ano | findstr :8000看输出里是否有LISTENING状态。没有 LISTENING说明服务没起来或者端口号不对。这一步能过滤掉大量无关干扰。4.2 证书验证失败CURLE_PEER_FAILED_VERIFICATION访问https://的接口时报错形如curl: (60) SSL certificate problem: self-signed certificate常见原因有三类服务器用的是自签证书服务器证书过期或域名不匹配本机系统时间错误导致证书有效期校验失败。这类场景多见于访问公司内网、本地测试环境或者某些老旧设备的管理接口。临时验证可以用-k跳过证书校验但脚本化和自动化场景里不建议写死-k它会关闭 TLS 的身份验证能力等于裸奔。更好的做法是拿到服务端的证书文件用--cacert指定curl.exe --cacert server-ca.pem https://api.example.com/health如果你是自签服务器还可以考虑把根证书导入 Windows 的受信任根证书存储。导入后curl 大概率就能直接通过校验不需要每次附加参数。注意证书问题不影响本机回显服务因为 127.0.0.1 默认走 HTTP不涉及 TLS。4.3 Windows防火墙或安全软件拦截还有一类问题请求目标没问题、服务也确实启动了但 curl 就是连不上。表现通常是连接超时或者报Connection refused。Connection refused 说明目标端口没有进程监听而超时可能意味着防火墙把包丢弃了。在 Windows 上排查时除了看服务日志还要考虑安全软件。某些安全软件会对curl.exe这种命令行网络工具做行为拦截尤其是第一次运行时弹窗请求网络权限没允许的话后续请求会一直被拦。判断方法很简单换一个网络请求工具试试比如用浏览器访问同一个地址如果浏览器正常而 curl 异常大概率是安全软件拦了 curl 的进程。另外注意回环地址127.0.0.1一般不会被防火墙拦但如果你请求的是局域网内另一台机器的服务Windows 防火墙可能会弹窗询问是否允许通信没有允许就会不通。这种“本机能通、跨机器不通”的现象优先检查双方的防火墙规则。4.4 响应内容与预期不符乱码、压缩、命令拆分响应能拿到但内容和预期不同这是最常见的第二类问题。先是乱码。curl 本身不会做字符集转换它只是原样搬运字节。如果服务端返回的是 GBK 编码而终端默认按 UTF-8 显示中文就会乱码。解决办法不在 curl而在显示端要么把响应保存到文件后用支持对应编码的编辑器打开要么让服务端改成返回 UTF-8。再是内容看起来像乱码二进制实际可能是压缩响应。服务器返回了Content-Encoding: gzipcurl 没有自动解压就会显示一堆乱码。这种情况加--compressedcurl 会自动发送带Accept-Encoding的请求并对返回的压缩内容自动解压。如果你不希望服务器压缩也可以用-H Accept-Encoding: identity明确要求不压缩。还有一种低级但常见的命令拆分。前面提到过URL 里的没加引号在 cmd 里会被当成命令分隔符。实际报错一般长这样age 不是内部或外部命令也不是可运行的程序或批处理文件。看到这个报错先回头检查 URL 是不是没包双引号。这类问题往往发生在切换终端环境后同一个命令在 Linux shell 下正常粘到 cmd 里就断成两截。5. 把curl写进Windows脚本与日常自动化几个可直接抄的片段5.1 cmd批处理中检查HTTP状态码并处理错误在.bat脚本里使用 curl最常用的需求是根据 HTTP 状态码决定后续流程。先看一个完整示例echo off setlocal set URLhttp://127.0.0.1:8000/health curl.exe -sS -o nul -w %%{http_code} %URL% code.txt set /p HTTP_CODEcode.txt echo HTTP_CODE%HTTP_CODE% if %HTTP_CODE%200 ( echo 接口正常 ) else ( echo 接口异常退出 exit /b 1 )这里有两个细节值得强调。第一-o nul把响应体丢弃-w %{http_code}只输出状态码。状态码被重定向到code.txt再用set /p HTTP_CODEcode.txt读回来。为什么不直接用%ERRORLEVEL%判断因为 curl 的退出码表示的是传输层是否成功比如服务器返回 404 或 500curl 退出码仍然是 0只有请求彻底失败连接不上、超时才有非零退出码。所以想判断 HTTP 语义必须把状态码拿出来。第二批处理文件里%的转义。上面代码写的是%%{http_code}两个%%最终会被 cmd 解释成一个%传到 curl 那边就是%{http_code}。如果你在 cmd 窗口里直接敲命令只写一个%即可写进.bat文件必须写两个否则变量解析会出错。这个坑即使老手也容易一时忘掉。5.2 PowerShell脚本中调用curl.exePowerShell 里调用外部 exe习惯上使用调用运算符方便同时拿到退出码和输出。按下 trap$url http://127.0.0.1:8000/health $code curl.exe -sS -o response.json -w %{http_code} $url if ($LASTEXITCODE -ne 0) { Write-Host curl 调用失败退出码: $LASTEXITCODE exit 1 } if ($code -ne 200) { Write-Host 接口返回异常状态: $code exit 1 } $data Get-Content response.json -Raw | ConvertFrom-Json$LASTEXITCODE是 PowerShell 里保存上次外部程序退出码的自动变量和 cmd 的%ERRORLEVEL%对应。这里我把-w %{http_code}用单引号包起来PowerShell 不会把%{http_code}解析成变量原样传给 curl省去转义烦恼。使用ConvertFrom-Json时特别注意curl 下载的文件如果带 UTF-8 BOMGet-Content -Raw能正常处理如果不带 BOM 且包含中文可能需要用-Encoding UTF8指定读取编码避免中文解析成乱码。5.3 接口冒烟测试与耗时统计把一组接口地址放进数组循环请求任何一个非 200 就失败退出这个模式非常适合部署后的冒烟验证。$urls ( http://127.0.0.1:8000/health, http://127.0.0.1:8000/api/v1/users, http://127.0.0.1:8000/api/v1/orders ) foreach ($u in $urls) { $code curl.exe -sS -o NUL -w %{http_code} $u if ($code -eq 200) { Write-Host $u OK } else { Write-Host $u FAIL: $code exit 1 } }如果还想看每个接口的耗时可以用-w把多个时间字段一起输出curl.exe -sS -o NUL -w 连接:%{time_connect}s 总耗时:%{time_total}sn http://127.0.0.1:8000/apitime_connect是 TCP 连接建立耗时time_total是请求从开始到结束的总耗时。在 Windows 终端里想要换行显示多个字段可以像上面这样在双引号里写反引号 n也可以配合echo换行。这个输出对粗略判断接口性能非常有用不用开任何图形化工具。5.4 组合参数处理不稳定网络重试与断点续传实际运行中最常见的问题不是接口逻辑错而是网络抖动导致请求失败。curl 自带了比较完善的重试机制curl.exe --retry 3 --retry-delay 2 --retry-connrefused --connect-timeout 5 -o data.txt http://127.0.0.1:8001/data.txt参数含义--retry 3表示最多重试 3 次--retry-delay 2表示重试前等待 2 秒--retry-connrefused让连接被拒绝时也参与重试--connect-timeout 5表示 TCP 连接超时 5 秒直接放弃。组合起来用在自动化下载场景里能大幅降低临时故障的影响。如果要下载大文件还可以把重试和断点续传合并curl.exe --retry 3 --retry-delay 2 -C - -o bigfile.zip http://127.0.0.1:8001/bigfile.zip这样当下载中途断掉时再次执行会从本地已有文件大小处继续请求剩余部分而不是重新下整个文件。我自己在 Windows 上处理定时任务下载时这一条命令基本没再出过“下载了一半就全丢”的问题。最后补一个我自己的使用习惯凡是涉及关键请求我都不直接在终端里敲长命令而是先写成脚本文件再执行。Windows 终端的引号、编码、%转义规则太多手敲出错概率高尤其在 cmd 和 PowerShell 之间来回切换时。遇到异常先跑一次-v把完整输出留档确认问题到底在连接阶段、证书阶段、还是业务逻辑阶段再对症下药。这套流程走熟之后curl 在 Windows 下基本不会给你拖后腿。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
