Multer处理含文件上传的对象数组请求的方案咨询

原生Multer不支持开箱即用实现该需求。
Multer的设计逻辑是将multipart请求中的普通文本字段和文件字段分开解析：文本字段填充到req.body，所有文件统一归集到req.files下，不会自动嵌入body里的嵌套对象、数组结构。
其提供的.fields()方法仅支持按传入的精确字段名做一级分组，不会识别字段名中方括号代表的嵌套路径（比如first[0][file]这类格式），因此拆分后的文件数组无法自动和body中同路径的对象绑定。靠文件名做匹配的方案确实不规范，一旦出现重名、客户端修改文件名、代理层调整字段传输顺序的情况，必然出现匹配错位。
如果要继续使用Multer，最稳妥的轻量改造方案不需要依赖文件名：

• 前端传FormData时，给嵌套数组的字段明确标注索引，比如第一个数组第一个对象的文件字段名设为first[0][file]，对应name字段设为first[0][name]，和普通文本字段的路径规则完全对齐
• 加一个10余行的后置中间件，遍历req.files下的所有文件，按照字段名的方括号路径递归挂载到req.body对应位置即可，匹配准确率100%。

如果不想自行编写映射逻辑，可以选择以下两类更适配的方案：

• formidable v3+：Node.js生态主流的流式multipart解析库，性能和Multer处于同一水平。它不会强制分离文件和普通字段，开发者可以通过监听字段、文件事件，按照字段路径直接组装成目标嵌套结构，不需要二次转换，适合对性能要求高、需要自定义解析逻辑的场景。
• express-fileupload：Express生态的轻量上传中间件，默认行为就是将所有文件按照字段路径直接挂载到req.body的对应位置，解析完成后拿到的req.body结构和示例中的uploadObject结构完全一致，不需要额外做映射匹配。缺点是默认配置下小文件会存储在内存中，大文件场景需要手动开启临时文件写入配置，高并发大文件上传场景下性能略低于流式解析库，普通业务场景使用完全足够。

通用注意点：不管使用哪个上传解析库，只要涉及数组类型的嵌套上传，前端传FormData时必须明确带上数组索引，不要使用无索引的first[][file]格式传参，否则一旦请求经过代理层打乱字段传输顺序，任何解析库都无法保证文件和同对象下其他字段的匹配关系。

内容的提问来源于stack exchange，提问作者Ashish Patel