绝大多数后端框架默认拦截空文件上传，会因Content-Length:0或RFC 7578合规性校验直接返回400/500；Spring Boot等解析器对空part处理策略不同，有的跳过、有的抛异常。
空文件上传会被直接拒绝吗？
绝大多数后端框架（如 Spring Boot、Express、Django）默认会拦截 Content-Length: 0 的 multipart part，或在解析时抛出 IOException / BadRequestException。不是 Postman 的问题，而是服务端对 RFC 7578 的严格实现：一个合法的 file 字段必须携带非空二进制内容，否则整个 boundary block 视为无效。你看到的 400 或 500，往往就卡在这一步。
Postman 怎么发一个真正的零字节文件？
Postman 的 form-data 模式下点 “Select Files” 选空文件（比如新建一个 touch empty.txt 的文件），它会正常提交——但注意：Postman 实际发送的是该文件的完整路径和原始字节，哪怕它是空的。关键在于服务端是否校验了 file.size == 0。
- 确保 key 名与接口文档一致（如
file、attachment、data），大小写敏感 - 不要手动设置
Content-Type头，Postman 会自动生成带正确boundary的multipart/form-data - 若需携带其他字段（如
title），必须设为text类型，不能和file共用同一个 key - 某些网关（如 Nginx）默认限制最小请求体为 1 字节，需显式配置
client_max_body_size 0和underscores_in_headers on
如何验证后端是否真校验了空文件？
光看状态码不够。空文件上传成功后，响应体里返回的 file.url 或 file.path 很可能指向一个占位符（如 /uploads/empty_abc123），但实际磁盘上没生成任何东西，或写入了一个 0-byte 文件。你应该：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 用 Postman 的
Tests标签页加断言：pm.response.code === 200 && pm.response.json().data.file.size === 0 - 检查响应头是否有
X-File-Size: 0这类自定义标识 - 如果接口支持下载，用同一请求 ID 调用下载接口，再用 Postman 的
pm.response.text().length === 0确认响应体确实是空的 - 服务端日志里搜
multipart part size=0或Empty file rejected，比前端反馈更准
容易被忽略的边界场景
真正上线后出问题的，往往不是“纯空文件”，而是那些看似有内容、实则无效的边缘 case：
-
.DS_Store、Thumbs.db这类系统隐藏文件，长度可能为 0，但扩展名不匹配白名单 - 文件名含 Unicode 零宽空格（
\u200B）或 BOM 头，导致服务端解析filename字段失败，间接让文件体被丢弃 - 多文件上传时，某一个 part 是空的，其他非空 —— 此时整个请求是否被整体拒绝，取决于后端 multipart 解析器的容错策略（如 Apache Commons FileUpload 默认跳过空 part，Spring
MultipartFile则可能报NullPointerException）
这些 case 在 Postman 里没法靠界面按钮触发，得靠 Pre-request Script 手动构造原始 body，或者改用 binary 模式 + 自定义 boundary 发送 raw payload —— 但那已超出 form-data 的语义范畴，属于协议层压测了。
