Postman上传文件返回415错误，主因是Content-Type与实际格式不匹配、form-data模式误切、Key字段名与后端不一致、服务端未启用multipart支持或Value类型开关误配。
Postman上传文件返回415，基本就是 Content-Type 声明和实际发送格式不匹配，不是服务器不支持文件上传，而是它根本没认出你发的是什么。
为什么选 form-data 却还报 415？
Postman里选了 form-data，不代表请求头自动加对了 Content-Type。它会自动生成类似 multipart/form-data; boundary=----WebKitFormBoundary... 的头，但这个行为只在 Body → form-data 模式下生效；一旦你误切到 raw 或 x-www-form-urlencoded，哪怕手动补上 Content-Type: multipart/form-data，服务器也收不到合法的 boundary 分隔符，直接拒收。
- 检查 Postman 左上角 Body 选项卡是否真处于
form-data（不是binary，也不是raw） -
form-data模式下，Content-Type头由 Postman 自动注入，**不要手动覆盖或添加** - 如果用了
binary模式上传文件，Postman 不会加Content-Type头，此时必须手动加，且值只能是application/octet-stream或服务端明确接受的类型（如image/png） - 上传多个文件时，每个
Key字段名必须和服务端接口文档一致，比如后端期待files，你填成file就可能触发 415（部分框架会因无法绑定参数而退回到 InputFormatter 校验失败）
form-data 下的 Key 值和服务端字段名不一致
Postman 的 form-data 表单里，每行的 Key 是字段名，Value 是值或文件。这个 Key 必须和服务端控制器方法的参数名、模型属性名、或 [FromForm] 绑定目标完全一致。例如 ASP.NET Core 中写的是 public IActionResult Upload([FromForm] IFormFile avatar)，那 Key 就必须填 avatar，填 file 或 image 都会导致绑定失败，进而 InputFormatter 找不到可解析的数据体，最终抛 415。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 确认后端代码中接收文件的参数名、属性名、或
name特性值（如[Name("user_avatar")]） - Postman 的
Key列必须与之一字不差，包括大小写 - 如果后端用数组接收（如
IFormFile[] files），Postman 要填多个同名Key，不能合并成一个 - 某些 Java Spring Boot 接口要求
@RequestParam("file")，那 Key 就必须是file，而非files
服务端没启用 multipart/form-data 支持
ASP.NET Core 默认支持 multipart/form-data，但如果你禁用了 MVC 的默认配置、或用了 Minimal API 且没显式添加 DisableRequestSizeLimit 和表单解析中间件，也可能在读取 body 前就因格式不识别而返回 415。Node.js 的 Express 默认不解析 multipart，必须靠 multer 等中间件；Spring Boot 则依赖 spring.servlet.multipart 配置项是否开启。
- .NET Core：检查
Startup.cs或Program.cs是否调用services.AddControllersWithViews()或显式注册FormOptions - Express：确认已
app.use(multer().any())或对应字段名的single()/array() - Spring Boot：确认
application.yml含spring.servlet.multipart.enabled: true - 所有框架都要注意：若前端传了空文件（未选中任何文件却提交），部分框架会把该字段当 null 处理，也可能绕过正常解析流程导致 415
最常被忽略的一点：Postman 的 form-data 模式下，如果某行 Value 是文本但你勾了 File 类型开关，它就会强行按文件上传处理——哪怕你填的是字符串。这种错配不会报错，但服务端收到的是带 boundary 的二进制流，却试图当纯文本解析，结果就是 415。动手前，盯住每一行的类型开关。
