Postman上传显示成功但后端未收到文件，主因是form-data中file字段类型未设为File、Content-Type被手动设置导致boundary丢失、后端接收字段名与Postman Key不一致。
Postman上传成功但后端没收到文件？先看响应体和日志
Postman 显示 200 OK 或 201 Created，不代表文件真被后端解析并保存了。很多框架（如 Spring Boot）在 multipart 解析失败时仍会进入控制器方法，只是 MultipartFile 参数为 null 或空，而你返回的响应是业务层写的“上传成功”，掩盖了底层失败。
实操建议：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 打开 Postman 右上角 View → Show Postman Console，发请求后点开对应条目，确认原始响应体里是否含真实业务结果（比如返回了
{"code":200,"msg":"file saved"}还是{"code":500,"msg":"file param is null"}） - 后端必须打日志：在接收文件参数后立刻加一行
log.info("Received file: {}", file != null ? file.getOriginalFilename() : "null") - 不要只依赖 HTTP 状态码——
400和500有时被全局异常处理器吞掉，转成200响应
form-data 中 file 字段类型选错是最高频原因
Postman 的 form-data 模式下，每个 Key 对应的 Value 必须显式指定类型。如果把文件字段的类型留在默认的 Text，它就真的当普通字符串发出去了——后端收到的是文件路径字符串（比如 C:\Users\...\test.jpg），不是二进制流。
实操建议：
- 在
Body → form-data表格中，找到文件字段那一行（例如Key = file） - 点击该行
Value右侧的下拉箭头，**必须选File**，不能是Text、Key-value或留空 - 选完
File后，右侧才会弹出文件选择框；如果只看到输入框，说明类型没切对 - 多个同名文件（如
files[]）要重复添加多行，每行都设为File类型
Content-Type 头被手动设置导致 boundary 丢失
Postman 在使用 form-data 时会自动生成带 boundary 的 Content-Type 头，形如 multipart/form-data; boundary=----WebKitFormBoundaryabc123。如果你手动在 Headers 标签页加了一条 Content-Type: multipart/form-data（没带 boundary），Postman 就会放弃自动生成，导致整个请求体结构不合法，后端解析器直接拒收。
实操建议：
- 删掉
Headers里所有手动加的Content-Type条目 - 确保
Body选项卡已选form-data，此时 Postman 底部状态栏会显示Content-Type: multipart/form-data; boundary=... - 如果用
raw或binary模式传文件，才需要手动设Content-Type；form-data模式下永远让 Postman 自己管
后端接收字段名与 Postman Key 不一致
Spring Boot 的 @RequestParam("file") MultipartFile file、Django 的 request.FILES.get('attachment')、Express + multer 的 upload.single('avatar')，这些括号里的字符串就是硬匹配的字段名。Postman 里 Key 写错一个字母、多一个下划线、大小写不对，后端就收不到。
实操建议：
- 查后端代码或 Swagger 文档，确认字段名是
file、upload、document还是dataFile - Postman
form-data表格中，Key列必须一字不差，包括大小写和下划线 - 特别注意数组字段：后端要
files[]，你就不能只写files；后端要image，你就不能写img - 用 Postman Console 查看发出的原始请求体，搜索
Content-Disposition: form-data; name="xxx"，确认 name 值是否匹配
