表单提交大文件必然失败，因浏览器会将全部文件读入内存拼装请求，导致内存溢出卡死；必须改用 File API 分片上传，配合服务端 content-range 支持与原子写入。
直接用 <form> 提交大文件必然失败——不是配置没调够，而是浏览器根本不会让你走完流程。
为什么表单提交扛不住大文件
浏览器在 form.submit() 触发后，会把所有 input[type="file"] 选中的文件一次性读进内存，拼成 multipart/form-data 数据体再发出请求。哪怕只是 5 个 300MB 的视频，内存占用就轻松突破 1.5GB，Chrome 直接卡死或弹出 “Aw, Snap!”，Firefox 可能无响应，Safari 会静默中断。
这不是你漏配了某个参数，是 HTML 表单规范本身不支持流式、分片或进度控制。你无法插入 file.slice()、无法监听单块进度、也无法在某片失败时只重传那一片。
-
files是只读FileList，但每个File实例仍持有完整文件引用，调用submit()就等于触发全量加载 -
enctype="multipart/form-data"只决定编码格式，不改变同步阻塞行为 -
webkitdirectory等扩展属性只影响选择范围，对提交机制毫无帮助
必须改用 File API + fetch / XMLHttpRequest
真正可控的入口只有一个：file.slice()。所有分片逻辑都得从这里开始，而不是试图用 readAsDataURL 或整文件 arrayBuffer() ——那等于主动引爆内存炸弹。
立即学习“前端免费学习笔记（深入）”；
- 分片大小建议设为
5 * 1024 * 1024（5MB）：太小导致 HTTP 头开销占比过高；太大易触发单次FileReader内存峰值 -
start和end必须是字节偏移量，不是字符数；最后一片要用Math.min(start + chunkSize, file.size)动态计算 - 每片上传后立即置空
reader = null，否则闭包持续持有Blob引用，V8 不敢回收 - 并发上传别用
Promise.all：浏览器同域并发fetch通常硬限 6 个，盲目并发反而因排队放大失败率
服务端必须配合 content-range 和原子写入
前端切片只是第一步，服务端若不按标准处理，多片并发写入会覆盖错位，合并后文件损坏。
- 每个请求必须带
Content-Range头，例如bytes 0-5242879/10485759，服务端靠它定位写入位置 - 不能简单追加到临时文件，必须按 offset 随机写入对应块（如用
fs.write(fd, buffer, 0, size, offset)） - 合并操作必须原子化：先校验所有分片 MD5/SHA1，再拼接，最后重命名覆盖目标文件，避免中间状态被访问
- 断点续传依赖服务端返回已上传分片索引（如通过
HEAD请求返回Content-Range），前端据此跳过已传部分
最麻烦的从来不是怎么切片，而是服务端如何可靠地记录状态、跨请求保持一致性、并在崩溃后精准恢复。前端能做的只是把每片干净、有序、带标识地送过去——剩下的，得靠后端真刀真枪地扛住。
