HTML表单大批量文件上传内存分段策略分析

先说结论：HTML 表单的原生提交机制，天生就不支持分段上传。它一旦接手，就是一次“全量发送”——把整个文件一股脑塞进请求体，前端完全无法干预。指望改个表单属性、加个 JS 钩子就能让它分段，从一开始就错了方向。

深入来看。当浏览器提交一个 enctype="multipart/form-data" 的表单时，它会将文件内容序列化成一整段连续的 multipart boundary 流。这个流中间无法打断，不能切片，也不能嵌入任何元数据。你完全控制不了它何时发送哪一段，更别指望监听“已发 30%”或重试某个分片。

• 所有文件必须先完整加载到内存（或临时磁盘缓存），然后再整体发出。一旦文件超过 100MB，极易触发 Chrome 的 RangeError: Maximum call stack size exceeded 错误，更直接的结果就是标签页卡死。
• 很多人以为通过 XMLHttpRequest.upload.onprogress 能监听进度，但该事件在标准表单提交中根本不生效。因为底层走的是同步导航流程，并非 XHR 那一套。
• 服务端接收到的永远是一个完整的 multipart/form-data 请求体。请求头里没有 Content-Range，也没有 chunkIndex，服务端想做断点校验或并行写入，完全无门。

为什么 File.prototype.slice() 才是唯一的切入点

所以，真正能在前端动手切割的，只有 File 对象本身。你必须绕开表单，用 JS 主动调用 slice() 方法提取二进制片段，再逐段构造请求。

• 参数单位是字节，不是 MB，也不是字符。想切 5MB，就得写 file.slice(0, 5 * 1024 * 1024)。直接写 file.slice(0, 5000000) 虽然数值上正确，但极易出错，不推荐。规范写法更清晰可靠。
• 边界防护必须做好。每次切片时，务必用 Math.min(start + chunkSize, file.size) 作为 end 边界判断。否则最后一片很容易越界，抛出 InvalidStateError。
• slice() 返回的是一个新的 Blob 对象，而非原对象的引用。不用担心原 File 被修改。另外，别为了它去用 URL.createObjectURL()，那个玩意如果不手动 revoke，会一直占用内存不释放。
• 兼容性方面，旧浏览器需要处理前缀，比如 file.webkitSlice?.(start, end) 或 file.mozSlice?.(start, end)。现代环境直接用 slice 就行。

并发上传必须节制，别拿 Promise.all 当万能药

想象一下，一个 1GB 的文件被切成 200 片，你要是图省事直接用 Promise.all(chunks.map(upload))，那后果就是瞬间向服务器发起 200 个请求。这直接撞上浏览器的同域并发上限（Chrome 默认 6 个）。结果大量连接被挂起，内存暴涨，页面无响应。

• 实战验证，安全的并发数在 3-5 路之间。靠谱的做法是用 Promise.allSettled 配合一个固定长度的队列，比如一次最多发 4 个，完成一个再补一个。别一股脑全扔出去。
• 每个请求必须独立创建一个 XMLHttpRequest 实例，上传完成后立即设为 null，避免实例堆积。细节决定成败。
• 每个片段的请求头里必须带上 Content-Range，比如 bytes 0-5242879/1073741824。服务端全靠这个信息来定位数据写入的位置。
• 别复用 FormData 实例。每片都要新建一个 new FormData()，然后再 .append('file', blob)。复用实例会导致 blob 引用错乱，数据不对，哭都来不及。

后端不配合，前端再努力也是白搭

前端切得再整齐、传得再稳，如果后端收完所有分片就丢进临时目录不管，或者合并时没按 chunkIndex 排序、没做哈希校验，最终的合并文件一定是损坏的。这个环节被忽略的尤其多。

• 需要确认后端是否提供了像 /upload/status?uploadId=xxx 这样的接口，用来查询已接收到的 chunkIndex 列表，这样前端才能知道哪些需要重传。
• 合并动作必须由服务端完成。它得扫描该 uploadId 下的所有临时文件，按 chunkIndex 升序排列，然后拼接起来。最后还得对整个文件计算一次 md5 或 sha256 做最终校验。
• 后端返回的错误信息要具体，比如 {"code": 4001, "msg": "chunk 5 missing"}，而不是简单的抛一个 500 错误。这样前端才能精准定位问题。
• 前端生成的 uploadId 也大有讲究。它必须基于文件指纹来生成，比如用 Web Crypto API 的 digest('SHA-256', buffer)。千万别用 Math.random() 或时间戳，不然同名文件反复上传会把之前的进度覆盖掉。

所以说，真正的分段上传，不是前端切几刀就完事。它是一套端到端的系统：前端切、传、重试、查进度；后端收、存、校、合、验。只有两端协议对齐了，这事才算真正落地。漏掉任何一环，用户点下上传按钮的那一刻，结局就已经注定是失败的。