Postman选了File但后端MultipartFile的getSize()为0，说明请求体已到达且解析出文件字段，但内容为空；最常见原因是未真正完成文件选择动作，仅打开对话框而未确认，导致Postman发出带multipart/form-data头却无实际文件内容的请求，Spring Boot仍创建空MultipartFile实例。
Postman里选了File但后端MultipartFile的getSize()是0
这说明请求体确实到达了服务端，也解析出了文件字段，但内容为空——最常见原因是Postman在没真正选中文件时，仍发出了一个带Content-Type: multipart/form-data头的请求。此时Spring Boot会创建一个MultipartFile实例，但getOriginalFilename()为空、getSize()为0。
检查步骤：
- 在Postman的
Body → form-data里，确认对应key（如file）的类型下拉框显示的是File，而不是Text - 点击
File右侧的Select Files，必须完成选择动作；只点开对话框但未点“打开”或“确定”，仍算未选 - 发送前看Postman底部状态栏是否显示“1 file selected”；没有则大概率发的是空文件
- 后端加一行日志：
log.info("filename={}, size={}", file.getOriginalFilename(), file.getSize());，避免只靠file == null判断
Postman发请求后服务端MultipartFile参数直接为null
不是空文件，是压根没绑定上，通常卡在协议层或绑定层。Spring Boot默认用@RequestParam接收时，字段名、Content-Type、请求体结构三者必须严丝合缝。
关键排查点：
-
Headers里不要手动设置Content-Type——Postman在form-data模式下会自动生成带boundary的完整头，手填反而可能覆盖掉boundary导致解析失败 - 确认
form-data中key名和后端@RequestParam("file")里的字符串完全一致，包括大小写和下划线 - 如果后端用
@RequestPart，前端必须用form-data且key不能是普通文本；@RequestParam更宽松，但要求字段名精确匹配 - Spring Boot 2.6+默认禁用
spring.servlet.multipart.enabled=true，但若项目显式关闭过该配置，需检查application.yml中是否误设为false
本地能传、测试环境传不了，getSize()始终为0
这种情况往往不是代码问题，而是网关或反向代理把multipart请求截断了。Nginx、Kong、API网关常有默认的client_max_body_size或maxRequestBodySize限制，小图能过，大图就静默丢弃部分内容，导致后端拿到的只是半截流。
验证与修复：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 抓包看实际发出的请求体长度（Postman右上角「Send and Download」→「Download response」旁的「View in Console」），再和服务端
request.getContentLength()对比，若后者明显偏小，就是中间层截断 - Nginx需确认
client_max_body_size设得足够大，例如client_max_body_size 50M;，并放在http或server块下 - Spring Cloud Gateway用户要检查
spring.cloud.gateway.httpclient.max-in-memory-size，默认只有2MB，超限后会把文件流转成EmptyMultipartFile - 阿里云SLB、腾讯云CLB等负载均衡器也有上传大小限制，需进控制台单独开启或调高
绕过Postman：用curl快速验证是不是工具问题
Postman界面操作多，容易漏步。用curl一条命令就能排除大部分干扰，直击核心逻辑。
执行以下命令（替换http://localhost:8080/upload和test.jpg）：
curl -X POST http://localhost:8080/upload \ -F "file=@./test.jpg"
注意点：
-
-F参数自动设置Content-Type: multipart/form-data并生成合法boundary，比Postman更“干净” - 确保路径正确，
@前不能有空格，@./test.jpg不能写成@ test.jpg - 如果
curl能成功而Postman不行，基本锁定是Postman配置或UI交互问题，不是后端逻辑缺陷 - 加
-v参数可看到完整请求头和响应，重点核对Content-Length和boundary是否生成正常
空文件问题最棘手的地方在于它不报错，也不中断流程，只是 quietly 返回一个size=0的对象。一旦依赖file != null做判空，就会漏掉这种“伪成功”。真正可靠的校验永远是file.getSize() > 0 && StringUtils.hasText(file.getOriginalFilename())。
