Axios 上传二进制文件，服务器却收到乱码字符串

上传内容本来是Blob，服务器收到的upload却是字符串，二进制中的0xFF还变成了替换字符。若Node使用Axios的http适配器，先检查FormData里是否显式传了空文件名。

例如 form.append('upload', blob, '') 在Axios1.20.0的这条路径中，可能被序列化成只有name、没有filename的multipart部分。很多接收器据此把它作为文本字段处理，而不是文件。

少了filename，接收类型就可能改变

formDataToStream通过value.name的真假决定是否添加filename。空字符串为假，因此不会写出 filename=""。这与完整保留空文件名并不等价：Content-Disposition中参数不存在，会影响接收方对该部分的分类。

Content-Type: application/octet-stream本身不能补回缺失的文件语义。也不要在接收端把已经解码成字符串的乱码再转成Buffer；原始字节可能已丢失，后续无法可靠恢复。

先确认运行产物的Axios版本、适配器、FormData和Blob是否为目标运行时的实现。这里不是一看到上传挂起就判断对象品牌不兼容，故障表现应包括已发出的multipart头和接收类型。

允许非空名称时，在加入FormData时明确提供

如果上传协议没有要求保留空名称，可以在生成该文件项的位置给出符合业务约定的文件名：

import axios from 'axios';

const form = new FormData();
form.append('upload', blob, 'upload.bin');
await axios.post(url, form, { adapter: 'http' });

blob和url来自应用现有的文件和目标配置，upload.bin只是二进制文件的示例名称。已有认证、超时、大小限制及其他字段应保留，不要用这段最小片段替换整套上传封装。让Axios处理multipart边界，不能手写一个缺少boundary的Content-Type覆盖它。

真实文件名参与业务规则时，应按已有校验选择名称。不要把本地完整路径当作文件名，也不要无条件改成另一个扩展名，误导内容类型或后续处理。

必须保留空文件名时，不要悄悄改协议

若接收方确实区分“空名称文件”和“普通字段”，改名不是等价修复。此时需要采用已核对的序列化实现或等待正式修正，并在原运行时验证完整multipart内容。切换fetch适配器还会影响进度、流和其他选项，需要按目标运行时独立验证，不能因为一次上传返回成功就批量替换。

正式Axios1.20.0的HTTP路径仍按value.name真假判断，不能声称已经自动保留空filename。验收要从服务器解析结果核对文件对象、名称、字节数和原始字节，特别覆盖包含非UTF-8字节的文件。还应验证原有文本字段及多个文件；HTTP成功响应并不能证明文件未被当成文本。