Postman 中传绝对路径报 java.io.FileNotFoundException 是因后端 JVM 在服务器上解析路径，而非本地；正确做法是改用 form-data 上传文件本身，或确保路径为服务器可见的网络路径/挂载卷。
Postman 里填了绝对路径但报 java.io.FileNotFoundException
这个错误不是 Postman 在找文件，而是后端代码在找——你传的只是个字符串路径，Postman 根本不读取本地文件系统。后端用 new FileReader(pythonScriptPath) 去打开它时，JVM 进程运行在服务器上（哪怕 localhost），它看到的 E:codeclustering.txt 是服务器自己的 E 盘，不是你本地电脑的。
常见错误现象：
- 你在 Windows 上复制了资源管理器里的完整路径粘贴进 Postman 的 text 字段，后端日志打印出的路径看着完全正确
- 把同一串路径写死在 Java 代码里却能读通——因为此时 JVM 运行在你的开发机，E 盘真实存在
- 部署到 Linux 服务器后，路径变成
/home/user/file.txt，但后端仍报找不到，因为文件根本没上传过去
正确做法：
- 如果接口本意是“上传文件”，就别传路径字符串，改用
form-data模式上传二进制文件本身 - 如果接口真要接收路径（比如调度任务读取共享存储），确保该路径对后端 JVM 可见：要么是网络路径（
smb://、\192.168.1.100share），要么是容器/服务器上已挂载的卷 - 避免使用盘符路径（
E:）、用户目录变量（%USERPROFILE%）、相对路径（./data/）——这些在服务端无意义
Postman form-data 里选了文件却后端收不到 file
后端抛 Required request part 'file' is not present，大概率不是没选文件，而是 Postman 构造的 multipart 请求体不符合框架解析预期。Spring Boot、ASP.NET Core 等都依赖标准 Content-Disposition 头里的 name 和 filename 字段。
关键检查点：
-
Key字段必须严格匹配后端参数名（如 Spring 的@RequestParam("file")或 ASP.NET 的IFormFile file），大小写、下划线都不能错 -
Key下拉菜单必须选File，不是Text；若误选Text并粘贴路径，Postman 会把它当纯文本发，不会带filename属性 - 不要手动设置
Content-Type: multipart/form-data请求头——Postman 会自动加带boundary的完整值，你手填的没boundary反而让后端无法解析 - 中文文件名在旧版 Postman 可能触发编码问题，临时改英文名测试，确认是否为 filename 字段解析失败
Postman 发送后端报错但 cURL 能通，怎么对比差异？
这是最有效的定位手段。Postman 的 form-data 表单看似简单，底层生成的 multipart 请求体其实包含 boundary 分隔线、换行符、双引号包裹的 filename、甚至多编码格式（filename*=）。cURL 默认行为更“原始”，反而容易绕过某些解析陷阱。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
操作建议：
- 在 Postman 右上角点
Code→ 选curl (bash)，复制生成的命令 - 对比关键字段：
-F "file=@/path/to/file.xlsx;type=application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"中的file名是否与后端一致、type是否被覆盖、是否有多个-F冲突 - 若 cURL 成功而 Postman 失败，大概率是 Postman 自动加的
filename*=编码被后端解析器拒绝（尤其老版本 Tomcat 或自定义解析器）；可尝试在 Postman 的 form-data 行右侧点铅笔图标，删掉filename*那部分，只留filename="xxx.xlsx"
为什么关掉 Postman 自动 Content-Type 反而更糟？
Postman 在 form-data 模式下，对每个字段单独设置 Content-Type：文件字段设为 application/octet-stream 或根据扩展名推断（如 .xlsx → application/vnd.openxmlformats-officedocument.spreadsheetml.sheet），文本字段设为 text/plain。你手动在 Headers 里填 Content-Type: multipart/form-data，等于覆盖了整个请求头，导致缺失 boundary，后端直接拒收。
真正需要干预的场景极少，仅限：
- 后端强制校验某字段的
Content-Type（如要求 XML 文件必须是application/xml而非text/xml），这时只改对应 form-data 行的Content-Type值，别碰 Headers - 上传空文件时，某些框架依赖
Content-Type判断是否跳过解析，此时需确保非空字段有合理类型
边界分隔符（boundary）和字段结构才是 multipart 的命脉，Content-Type 只是辅助。盯着 headers 改，不如打开 Code 看 cURL 生成的 -F 参数是否完整。
