使用 curl 上传文件失败主因是 -f 仅适用于 multipart/form-data 表单接口，而多数 api 实际需 application/octet-stream 或 json base64；应据文档选 -f（表单）、--upload-file（二进制直传）或定制 json 封装。
curl -F 上传文件时为什么服务器收不到数据
因为 -F 默认以 multipart/form-data 编码模拟表单提交，但很多后端接口实际期望的是原始二进制流（比如 PUT 接口）或 application/json 包裹的 base64。直接用 -F 往非表单接口发，服务端解析失败是常态。
- 确认目标接口文档：是接收
multipart/form-data（如 PHP 的$_FILES）、application/octet-stream（如对象存储直传），还是需要 JSON 封装？ - 表单上传场景才用
-F，例如：curl -F "file=@/path/to/image.jpg" https://api.example.com/upload -
@符号必须紧挨file=，中间不能有空格；路径错误会导致静默失败（curl 不报错，但 body 为空） - 如果后端用 Node.js Express +
multer，需确保字段名（如file）和服务端配置的name一致
用 curl PUT 上传大文件时连接被重置
默认 curl 使用短连接，且无分块、无进度反馈，大文件易超时或被中间代理切断。这不是 curl 本身的问题，而是传输模式不匹配。
- 加
-H "Content-Type: application/octet-stream"明确类型，避免服务端按 text 解析乱码 - 强制使用 HTTP/1.1 并禁用 chunked 编码：
curl -X PUT --http1.1 --upload-file /big.zip -H "Transfer-Encoding:" https://storage.example.com/file.zip -
--upload-file比-d @file更可靠：它不读入内存，适合 GB 级文件；而-d @file会尝试加载整个文件到内存再发 - 某些 CDN 或 Nginx 默认限制 body 大小，需同步调高
client_max_body_size和超时参数
上传带认证或特殊 Header 的文件总返回 401 或 400
Header 顺序和值格式稍有偏差就会触发鉴权失败或解析异常，尤其是含空格、引号、特殊字符的 token。
- Token 中若含点号或斜杠，用单引号包裹整个 header：
-H 'Authorization: Bearer eyJhb...'，避免 shell 把$或!当变量展开 - 上传同时带多个 header 时，每个
-H必须独立写，不能合并：-H "X-Upload-ID: abc" -H "X-File-Name: log.txt" - 部分 API 要求
Content-MD5，得先算哈希：md5sum file.pdf | cut -d' ' -f1，再拼进 header，少一位都会 400 - 用
-v看真实请求头是否符合预期，别只信文档——有些服务对 header 大小写敏感（如X-Amz-Date不可写成x-amz-date）
如何让 curl 上传时显示进度并自动重试失败
原生命令不支持断点续传，但基础进度和简单重试可以靠参数组合实现，复杂逻辑建议交给脚本封装。
- 加
--progress-bar显示实时进度条（不是百分比数字，是横向填充）；加-#是另一种风格，二者不可共存 - 网络抖动导致失败时，
--retry 3 --retry-delay 2可重试 3 次，每次间隔 2 秒；注意：仅对网络层失败有效，HTTP 4xx 错误不会重试 - 上传中途 Ctrl+C 不会自动清理已发部分，服务端可能收到残缺文件——务必确认后端支持校验（如比对
Content-Length或 MD5） - 真正需要断点续传（比如上传到 S3 分片），得换用
awscli或rclone，curl 做不了
-F 和一个 --upload-file 的差别，背后是两种完全不同的数据协商机制。搞混了，连错误提示都可能是误导。
