Postman上传压缩包失败主因是Content-Type未被识别、boundary被干扰或后端校验拦截扩展名/MIME类型；需确保form-data字段名准确、Type选File/Files、避免手动覆盖multipart头，并验证文件完整性与服务端限制。
Postman 上传压缩包（如 .zip、.tar.gz）本身没有特殊限制，但实际失败往往不是因为“不能传”，而是 Content-Type 未被服务端识别、boundary 被手动干扰、或后端校验逻辑拦截了扩展名/MIME 类型——这些才是你卡住的真正原因。
Postman 上传压缩包时 Content-Type 怎么设
Postman 默认在选择文件后会自动推断并设置 Content-Type，比如选 archive.zip 通常会设为 application/zip；选 data.tar.gz 可能设成 application/gzip 或 application/x-gzip。但很多后端只认特定值，比如强制要求 application/octet-stream 或忽略 MIME、只看文件扩展名。
- 如果上传被 400 拒绝，先检查响应体是否提示 “unsupported media type” 或 “invalid file extension”
- 手动覆盖
Content-Type：在Headers标签页添加一行Content-Type: application/zip（注意：这不是必须的，Postman 会自动生成 multipart 的顶层Content-Type，此处指 body 中该文件字段的子类型，实际需靠form-data的Content-Disposition和隐含 MIME 协同生效；更稳妥的做法是在Body → form-data中右键对应 key → “Edit value as text”，然后手动补全Content-Type行） - 常见压缩包 MIME 映射：
.zip→application/zip，.tar.gz→application/gzip，.7z→application/x-7z-compressed
form-data 中 file 字段名和多文件上传怎么配
后端接口文档里写的参数名（比如 file、upload、archive）必须一字不差填进 form-data 的 Key 栏；大小写、下划线、中划线都敏感。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 单个压缩包：Key 填
file，Type 选File，点右侧按钮选中本地.zip文件 - 多个压缩包同时上传：Key 仍填
file，但 Type 选Files（注意是复数），然后可按住 Ctrl/Cmd 多选多个.zip文件 - 如果后端要求数组形式（如 Spring Boot 的
@RequestParam("files") MultipartFile[] files），Key 填files[]，Type 选Files；不加[]就只能传一个 - 别在 Headers 里重复加
Content-Type: multipart/form-data——Postman 会自动生成带boundary的完整头，手动加反而可能破坏 boundary 对齐，导致 400
上传大压缩包超时或 413 错误怎么调
Postman 默认请求无超时限制，但若压缩包 >20MB，常因网络抖动或服务端限制失败。错误码 413 Payload Too Large 是 Nginx/Apache 或后端框架（如 Express、Spring）主动拒绝，和 Postman 无关。
- 先确认服务端限制：查 Nginx 配置是否有
client_max_body_size 50M；Spring Boot 是否设了spring.servlet.multipart.max-file-size=50MB - Postman 端可调超时：进入
Settings → General → Request timeout (ms)，设为60000（60秒）以上，避免中途断连 - 别用 Pre-request Script 分片上传——Postman 不支持原生分片构造 multipart 请求；真要测分片，得换
curl或写脚本 - 临时验证可用小压缩包：用
zip -r test_small.zip README.md打个几 KB 的包先跑通流程
如何验证压缩包是否真的传成功了
光看状态码 200 不够。服务端返回的 JSON 里如果有 filename、size、md5 字段，就拿去比对；没有的话，就得靠后续动作反推。
- 响应体中检查
"original_filename": "data.zip"和"size": 1234567是否匹配你选的文件 - 如果接口返回了可访问的下载 URL（如
"url": "/download/abc123.zip"），立刻用 Postman 新建 GET 请求访问它，看能否正常下载且解压内容完整 - 服务端日志最准：让开发帮你 grep 关键字，确认接收到的文件名、字节数、MIME 类型是否与你发送的一致
- 注意中文路径：如果压缩包名含中文（如
报告_2026.zip），部分旧服务端未做 UTF-8 解码，会导致文件名乱码、保存失败——换英文名重试是最快排查法
真正容易被忽略的是：后端往往在接收后立即校验压缩包结构（比如用 zip -T 测试是否损坏），而这个校验失败通常只返回泛泛的 400，不会告诉你“CRC 校验失败”。所以上传前务必用系统自带解压工具打开确认能正常读取——别信“文件存在”就等于“文件完好”。
