Postman不处理同名文件逻辑，服务端决定覆盖、拒绝或重命名；需通过“上传→下载→哈希校验”闭环验证真实行为，而非仅依赖200响应。
Postman 本身不处理同名文件的重命名或覆盖逻辑，它只负责把选中的文件原样打包进 multipart/form-data 请求体；服务端是否拒绝、覆盖、重命名，完全取决于后端代码实现——测试时必须主动验证这个行为，不能默认“上传成功=文件已存”。
为什么上传同名文件后接口返回200，但实际没存或被覆盖了？
这是最典型的误判场景。Postman 发送请求后看到 200 OK 和 JSON 响应，就以为上传成功，但响应里返回的路径可能指向一个旧文件，或者服务端静默覆盖了原文件，甚至直接报错却没在响应体里体现（比如写磁盘失败但 HTTP 状态码仍是 200）。
- 后端未校验文件是否存在，直接
file.write()覆盖 - 后端做了存在性判断但逻辑有缺陷：比如只比对文件名，没比对内容哈希，导致不同内容同名文件被当成重复而跳过
- 服务端返回的
data.file字段是硬编码路径（如"/upload/test.png"），而非真实保存后的唯一路径 - Postman 默认不显示响应体二进制内容，如果服务端出错返回 HTML 错误页，你根本看不到 —— 因为状态码是 200，Body 却是
Permission denied
怎么用 Postman 验证重名文件的真实处理逻辑？
核心思路：不依赖响应体文字，而是通过「上传→下载→比对」闭环验证。Postman 支持直接下载响应体为文件，并可配合 Tests 脚本做哈希校验。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 先用 Postman 上传一个已知内容的文件，比如
report_v1.pdf（内容为 "version: 1"） - 记录响应中返回的
data.file路径（如/media/report_v1.pdf） - 新建一个 GET 请求，URL 填该路径，Headers 加
Accept: */*，发送后点击Send and Download - 下载完成后，用 Postman 的 Tests 标签页写校验脚本：
const fileHash = CryptoJS.SHA256(responseBody).toString();<br>pm.test("文件内容未被覆盖", function () {<br> pm.expect(fileHash).to.eql("a1b2c3..."); // 替换为 report_v1.pdf 的真实 SHA256<br>}); - 再上传同名但内容不同的
report_v1.pdf（内容改为 "version: 2"），重复下载+校验，看哈希是否变化
Postman 中容易忽略的重名测试细节
很多团队卡在这一步：以为“两次上传同名文件都返回 success”，就认为没问题，其实漏掉了关键控制点。
-
form-data的 key 名必须和服务端约定一致（如后端接收字段叫document，你就不能填file，否则后端压根收不到，自然也不会走重名逻辑） - 上传多个同名文件时（比如两个
avatar.jpg），Postman 允许在同一个 key 下选多个文件，但后端是否支持数组解析、是否逐个校验重名，需单独测 - 文件名含中文或特殊字符（如
订单-2026-11-05.xlsx）时，服务端若未正确解码filename*参数，可能导致“看似同名实则不同名”的假象 - Postman 的 Collection Runner 批量上传时，若用环境变量动态替换文件路径，要确认每次迭代是否真加载了不同内容的同名文件，而不是反复读取缓存副本
真正可靠的重名测试，不是看接口返回什么，而是拿到服务端落盘后的文件，用哈希或内容比对确认它和你传的一致——哪怕后端声称“已自动重命名”，你也得下载那个新名字的文件，验证它确实是你要传的内容。
