Axios URL 编码嵌套 Buffer 后，两个字段都变成 file

提交两个嵌套对象，各自有一个Buffer类型的file，服务器却只看到两个同名file字段。普通嵌套字符串又能保留路径，应检查Axios的Node自动URL编码分支。

在Axios1.20.0中，下面这种数据配上application/x-www-form-urlencoded会命中特定处理：

{
  first: { file: Buffer.from('abc') },
  second: { file: Buffer.from('xyz') },
}

Buffer分支把内容转成Base64后，直接append当前key，没有使用path。最终键可能都是file，而不是first[file]和second[file]。服务器即使保留了两个值，也失去了它们属于哪个父对象的信息。

内容编码正确，不表示字段路径正确

修改dots选项也不能补上这一分支忽略的父路径。正常字符串走默认visitor，Buffer走提前返回的特殊路径，两者才会表现不同。

先从服务端解析前的表单键或受控请求中核对结构，不输出真实二进制内容。还应检查实际运行时和Axios副本；浏览器里没有同一套Node Buffer分支，不适合用一次浏览器请求代替复查。

固定协议可以显式编码完整键

若服务端原本约定接收Base64字符串，并按方括号解析嵌套路径，可以在请求边界直接建立URLSearchParams：

import axios from 'axios';

const body = new URLSearchParams();
body.append('first[file]', firstFile.toString('base64'));
body.append('second[file]', secondFile.toString('base64'));
await axios.post(url, body, {
  headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
});

firstFile、secondFile应是已经确认的Buffer，url来自应用原有目标配置。这段只展示两个受影响字段；其他字段、超时、认证与错误处理仍需保留。URLSearchParams会负责URL编码，不要先手工encodeURIComponent，再让它重复编码。

若后端采用点路径，则按接口契约使用first.file和second.file。括号本身不会让任意服务器自动生成嵌套对象，需要确认实际表单解析器的配置与深度限制。也不要让外部输入自由决定任意对象路径。

不把Buffer简单转成普通UTF-8字符串

原分支使用Base64。直接调用默认toString会把二进制按文本解码，某些字节会被替换，协议内容也发生变化。显式使用相同Base64表示，再让正常的字段路径编码生效，才保持了这条已知契约。

改用JSON或multipart也是可选的协议设计，但需要服务器配合，不能只改请求头。大二进制文件还要考虑Base64与表单编码带来的体积增长，沿用请求体上限，不能为了传过去取消全部限制。

当前正式1.20.0仍直接append当前key，未核证正式自动修复。验收应覆盖两个父对象下的同名字段、顶层Buffer、普通字符串和重复键，核对完整键、解码后字节和后端嵌套结果。只确认服务器拿到了YWJj，并不能证明它仍属于first.file。