formdata 提交二进制文件本身不慢，性能瓶颈在于服务端解析 multipart/form-data 时默认将整个请求体读入内存，易引发 oom 或阻塞；应改用流式上传、禁用全量缓存、客户端预校验与压缩，并前后端协同优化边界处理逻辑。
直接用 FormData 提交二进制文件（如图片、音频）本身不慢，真正卡住的是服务端对 multipart/form-data 的解析逻辑——尤其当字段混杂大量文本 + 多个大文件时，Node.js 的 busboy 或 PHP 的 $_FILES 默认行为会把整个请求体读入内存再拆包，极易触发 OOM 或长阻塞。
表单中怎么构造二进制数据流而不依赖 FormData
绕过 FormData 可以更精细控制二进制流，适用于需自定义边界、压缩或加密的场景：
- 手动拼接 multipart boundary：用
Uint8Array构建原始字节流，避免字符串拼接产生的编码开销 - 从
input[type="file"].files[0]获取Blob后调用.arrayBuffer()，再用new Uint8Array(arrayBuffer)直接操作字节 - 若需流式上传（如边录边传），用
ReadableStream+fetch()的body参数传入，配合Content-Type: multipart/form-data; boundary=...手动设置头 - 注意：浏览器不会自动补全
Content-Length，必须自己计算并设置，否则服务端可能等待超时
服务端解析 multipart 时最常见的性能陷阱
不是框架不行，是默认配置没关掉“全量缓存”：
- Express +
multer：默认inMemory: true，所有文件都进 RAM；应设dest到磁盘，或用fileFilter提前丢弃超限文件 - Node.js 原生
http模块：req.on('data')收到的是 Buffer 流，但若不做pause()/resume()控制，小 chunk 频繁触发 GC - PHP：
upload_max_filesize和post_max_size设得过大，但memory_limit不匹配，导致解析中途 kill 进程 - Python Flask：
request.files触发完整解析，哪怕你只想要文件名；应改用request.stream+werkzeug.formparser.MultiPartParser手动流式读取
前端如何让服务端解析更快一点
关键不是传得快，而是让服务端少做无用功：
- 提交前用
input.files[0].size做客户端尺寸校验，避免无效上传走完网络再被后端拒收 - 对图片类文件，提前用
canvas.toBlob()压缩降质，减小传输体积和解析压力 - 多个小文件合并为一个 ZIP Blob 再上传，减少 multipart boundary 解析次数（服务端用流式 ZIP 解包）
- 禁用表单自动填充（
autocomplete="off"），某些浏览器会在 submit 前同步扫描所有字段生成 autofill 数据，拖慢序列化
真正难的不是构造二进制流，而是让服务端解析器不把整块 buffer 拷贝三遍再拆包——这需要前后端对 multipart 边界处理逻辑有共识，而不是各自按默认值硬扛。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
