Postman选form-data却报“no multipart boundary was found”，说明请求未真正按multipart规范发出；根本原因是手动添加了不带boundary的Content-Type头，覆盖了Postman自动生成的含boundary的完整header，导致服务端无法识别分段边界。
Postman 选了 form-data 却报 “no multipart boundary was found”
这说明 Postman 没有真正发出 multipart 请求，而是发出了一个“假 multipart”——表面选了 form-data，但底层没生成 boundary，也没按 multipart 规范组织请求体。最常见原因是手动加了 Content-Type 头，覆盖了 Postman 自动构造的带 boundary 的 header。
你只要做三件事：
- 删掉所有手动添加的
Content-Type头（尤其是multipart/form-data这种不带 boundary 的写法） - 确保 Body → form-data 中至少有一个字段类型是
File（不能全是 Text） - 发送后打开 Postman Console，检查原始请求头里是否出现类似
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary...的行
如果 Console 里看到的是 Content-Type: multipart/form-data（后面没分号和 boundary），那一定是哪里手抖加了 header。
为什么删了 Content-Type 头反而能好？
Postman 的 form-data 模式不是“设置类型”，而是“触发 multipart 构造”。它只在检测到至少一个 File 类型字段 + 无手动 Content-Type 时，才自动生成 boundary、拼装分段结构、注入完整 header。一旦你显式设了 Content-Type，Postman 就放弃自动构造，直接用你给的值发出去——而你给的几乎肯定是不带 boundary 的裸字符串。
这个行为和浏览器、wx.uploadFile、fetch + FormData 完全一致：boundary 必须由客户端底层生成并同步写入 header 和 body，不能靠人肉拼接。
Postman Console 里能看到 boundary，但服务端还是报错
这时候问题不在 Postman 配置，而在服务端或中间链路。常见情况有：
- 网关（如 Nginx、Kong、Spring Cloud Gateway）重写了
Content-Type头，删掉了 boundary 参数 - 反向代理或 WAF 清洗了 multipart 请求体，把 boundary 行当垃圾过滤了
- Spring Boot 项目里有 Filter 提前调用了
request.getParameter()，导致请求体流被提前读空，后续 MultipartResolver 解析失败 - 服务端用了非标准解析器（比如自己用
BufferedReader读 raw body），没按 RFC 7578 规则识别 boundary 行
验证方式：用 Wireshark 或 tcpdump 抓包，对比 Postman Console 里的请求体和实际发出去的字节流是否一致。如果抓包里 boundary 已消失，问题一定出在客户端和服务端之间的某一层。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
文件字段名对了，boundary 也有了，还是提示 “file part not present”
这通常不是 boundary 缺失，而是 boundary 存在但服务端找不到对应字段。关键点在于 Content-Disposition 头的 name 值是否匹配。
比如你在 Postman 里 Key 填的是 file，但请求体中实际生成的是：
--boundary123 Content-Disposition: form-data; name="file"; filename="a.jpg"
这是对的；但如果生成的是：
--boundary123 Content-Disposition: form-data; name="file_upload"; filename="a.jpg"
那就匹配不上。这种错常见于：
- Postman 字段 Key 名含空格或特殊字符（如
file name），被自动转义或截断 - 后端框架（如 Spring）配置了
@RequestParam("uploadFile")，但 Postman 写的是file - 多文件上传时用了数组语法（如
files[]），但后端没开多 part 支持
最稳的查法：在 Postman Console 里点开 “Request Body”，看原始文本里每个分段的 name= 是什么，一字不差地对齐后端接收参数名。
