Postman Runner 批量上传文件必须用带盘符的绝对路径，开启“Allow reading files outside working directory”，form-data key 名须静态且与后端 @RequestParam 一致，Pre-request Script 中需用 pm.files.exists() 校验路径，避免并发过高导致文件句柄耗尽。
Postman Runner 里上传文件必须用绝对路径
Postman Runner 批量运行时无法识别相对路径或拖放式选择的文件，所有 file_path 必须是带盘符的绝对路径（如 C:dataimg1.jpg 或 /home/user/docs/file.pdf），且路径中不能有未转义的空格或中文——否则直接报 File not found 错误。
常见错误现象：单个请求能传，Runner 里全失败；CSV 中写 ./images/a.png 或 images/b.jpg，运行时报路径不存在。
- Windows 下路径用正斜杠
/或双反斜杠\，避免单个被当转义符（C:/temp/file.jpg✅，C: emp ile.jpg❌） - CSV/JSON 数据文件中，每个
file_path字段值必须用英文双引号包裹，尤其含空格时："C:/My Photos/photo 1.png" - Postman 设置里的
Allow reading files outside working directory必须开启（Settings → General → 最底部）
form-data 中 key 名必须和后端 @RequestParam 保持一致
Runner 批量上传本质是多次重复发送同一请求模板，所以 form-data 的 key 名不能动态变化（比如想用 {{key_name}} 替换），它必须是静态字符串，且与 Spring Boot 后端的 @RequestParam("files") 或 @RequestParam("file") 完全匹配。
如果后端接收的是 List，Postman 的 key 就得固定填 files；若后端是 MultipartFile file，那 key 就只能是 file —— 混用会导致后端收不到或只收到第一个文件。
- 不要在 key 栏写
{{param_key}}，Runner 不支持变量替换 key 名 - 多个文件共用同一个 key（如都叫
files），不是files[0]、files[1]等形式 - 如果需同时传额外参数（如
category），用 Text 类型添加，别和 File 混在同一个 key 行
Pre-request Script 中必须校验文件是否存在
Runner 不会主动告诉你哪个文件路径错了，等发完请求看到一堆 400 或 500 才回头排查。最省事的方式是在 Pre-request Script 里加一行检查：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
const filePath = pm.iterationData.get("file_path");
if (!pm.files.exists(filePath)) {
throw new Error(`文件未找到: ${filePath}`);
}
这段脚本能立刻中断当前迭代，并在控制台输出具体缺失路径。没有它，漏传文件可能静默失败，尤其当 CSV 里夹杂了已删除或移动过的旧路径时。
- 仅当数据文件中定义了
file_path字段时才可用此脚本 -
pm.files.exists()在 Postman v10+ 支持，旧版本需降级或改用其他校验方式 - 别把校验逻辑放在 Tests 里——那时请求已经发出去了
Runner 并发设置不当会导致文件句柄耗尽
默认 Runner 并发为 1，但手动调高（比如设成 5）后，若上传的是大文件（>10MB）或数量多（>50 个），容易触发系统级限制：Windows 报 EMFILE: too many open files，Linux/macOS 报 ENFILE 或连接超时。
这不是 Postman bug，而是操作系统对单进程可打开文件数的硬限制。Spring Boot 默认 Tomcat 连接池也吃不消高频 multipart 解析。
- Delay 建议设为
500ms 起，避免瞬时压力 - 大文件场景下，优先降低 Iterations 单次运行量，分批跑（比如 20 个/批）
- 服务端要检查
spring.servlet.multipart.max-file-size和max-request-size是否足够，否则文件直接被网关截断，连日志都不留
实际批量上传最易卡住的地方不在接口逻辑，而在 Runner 对文件路径的“零容忍”和并发时系统资源的隐性消耗——这两点不提前压测验证，跑一半失败还得翻日志逐条对路径。
