先说结论：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()或时间戳，不然同名文件反复上传会把之前的进度覆盖掉。
所以说，真正的分段上传，不是前端切几刀就完事。它是一套端到端的系统：前端切、传、重试、查进度；后端收、存、校、合、验。只有两端协议对齐了，这事才算真正落地。漏掉任何一环，用户点下上传按钮的那一刻，结局就已经注定是失败的。
