Postman发送二进制文件应选binary模式并避免手动设置Content-Type头；binary发送裸字节流（默认application/octet-stream），而form-data则封装为多部分消息，二者不可混用。
Postman 发送二进制文件，核心就两条：用 binary 模式选文件，且别乱设 Content-Type 头。 其他所有纠结——比如该不该加 boundary、要不要手动写 MIME、为什么后端收不到原始字节——基本都源于这两点没守牢。
为什么选 binary 而不是 form-data
二者本质不同：binary 发的是裸二进制流，HTTP 请求体就是文件原始字节，Content-Type 默认为 application/octet-stream；而 form-data 是带边界（boundary）的多部分消息，哪怕只传一个文件，也会被包装成类似 Content-Disposition: form-data; name="file"; filename="a.jpg" 的结构。
- 后端明确要求接收 raw binary（如某些 IoT 设备协议、加密载荷接口、C# 的
Request.Body直读场景），必须用binary - 后端用 Spring
@RequestParam MultipartFile或 PHP$_FILES解析，那得用form-data，且 key 名要和后端参数名一致 - 用
binary时，Postman 不会自动加Content-Type头；用form-data时，它会自动加multipart/form-data; boundary=...，你改不了这个行为
binary 模式下 Content-Type 怎么设
绝大多数情况下，不填 Content-Type 头。Postman 在 binary 模式下默认不发送该头，服务器收到的就是纯字节流，由后端自行按协议约定处理。
- 如果后端强依赖某个
Content-Type（比如必须是application/vnd.custom-encrypted），才在 Headers 里手动加，值填后端文档指定的字符串 - 千万别填
multipart/form-data或application/json——这会导致后端解析器试图按对应格式解包，直接报错或读出乱码 - 曾有案例：加了
Content-Type: text/plain，后端用StreamReader读取，结果 UTF-8 BOM 被当作文本处理，首字节丢失
文件生成和传输过程中的字节一致性
你本地保存的文件字节数，必须和 Postman 实际发出的字节数一致。常见断点在这里：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- Java 侧用
String.getBytes()再写文件，会导致编码膨胀（如中文变 3 字节），应直接操作byte[]写入FileOutputStream - 前端调试时用在线 Base64 转二进制再下载，容易因换行符或 padding 导致末尾字节错位
- Postman 的
binary上传按钮点选后，右上角会显示文件名和大小（单位 byte），务必和源文件ls -l或stat输出比对
验证请求是否发对了的最简方式
别急着看业务响应，先确认底层字节没错：
- 后端打日志：读取前 16 字节和最后 16 字节的十六进制（例如
Arrays.toString(Arrays.copyOf(bytes, 16))），和原始文件 hexdump 对比 - 用 Wireshark 抓包，过滤
http.request.method == "POST"，直接查看 TCP payload 的原始字节（需关闭 TLS） - 临时起一个 Python HTTP 服务（如
python3 -m http.server 8000配合自定义 handler），把self.rfile.read()全量存盘，再cmp校验
二进制调试里，最危险的不是“没发出去”，而是“发出去了但悄悄变了样”。每次换环境（比如从本地切到 CI）、换文件（比如图片换成加密 blob），都得重新校验字节长度和首尾特征。
