超大文件上传必须手动分片，推荐2MB/片，用File.slice()切片并校验边界；需断点续传（依赖服务端/status接口）、限流并发（≤5片）、显式处理HTTP状态码、禁用重定向、使用AbortController超时控制。
直接用 FormData + fetch 做超大文件上传，不手动分片就一定会失败——不是卡死、就是 RangeError: Maximum call stack size exceeded，或者服务端直接 413 Request Entity Too Large。真正能跑通的方案，必须自己切片、自己管理状态、自己重试。
File.slice() 切片时必须控制单片大小在 2–5MB
切片太大（比如 20MB/片），file.slice() 返回的 Blob 在构造 FormData 时会触发 V8 内存暴涨，Chrome 极易崩溃；切太小（如 100KB）则 HTTP 开销剧增、服务端压力翻倍。
-
CHUNK_SIZE = 2 * 1024 * 1024是当前最稳的起点，兼顾内存、网络、服务端写入效率 - 必须用
file.slice(start, end)，不是ArrayBuffer.slice()—— 后者不返回 Blob，FormData.append('file', ...)会静默失败 - 注意边界：
end = Math.min(file.size, start + CHUNK_SIZE)，否则最后一片可能越界报错
断点续传依赖服务端 /upload/status 接口，前端不能只靠 localStorage 记录
用户刷新页面后，前端需要立刻知道哪些 chunkIndex 已落盘成功。仅靠前端存 localStorage 或变量，无法应对服务端写入失败、Nginx 缓存假 200、磁盘满等真实异常。
- 上传前必须先发 GET 请求：
fetch(`/upload/status?uploadId=${uploadId}`) - 服务端该接口应返回已成功写入的
chunkIndex数组（如[0,1,3,5]），且每个 index 必须经幂等校验（比如检查对应临时文件是否存在 + size 匹配） - 前端跳过这些 index，但不要假设“没返回就是没传”——要容错：若接口 500 或超时，按全量重试策略走（比如最多重试 2 次，再失败就提示人工介入）
fetch 上传单片时必须显式处理 2xx 以外的所有状态码，且禁用 redirect
fetch 默认跟随重定向，而分片上传接口若被 Nginx 或网关 302 到登录页，前端会静默把 chunk 传到错误地址，服务端收不到、前端还认为成功了。
- 务必加
redirect: 'error'，强制中断任何重定向 - 检查
response.ok不够——要明确判断response.status === 200，因为部分服务端对重复上传返回 204，对校验失败返回 409，这些都需分类处理 - 网络中断或超时不能只靠
catch：要设signal+AbortController，例如const controller = new AbortController(); setTimeout(() => controller.abort(), 120_000); fetch(..., { signal: controller.signal })
并发上传必须限流，5 片并行是安全上限
浏览器对同一域名的并发连接数有限制（通常 6 个），如果所有分片一股脑 Promise.all 发出去，极易触发 TCP 队列堆积、TLS 握手阻塞，导致大量请求卡在 pending 状态，实际吞吐反而暴跌。
- 用
Promise.allSettled(chunks.slice(i, i+5).map(uploadOneChunk))分批执行，每批间隔 100ms 可进一步平滑压力 - 每片上传成功后，**立刻重新查一次 /upload/status**，避免因服务端异步合并逻辑延迟，导致后续片被误判为“未上传”而重复发送
- 别在
then里直接递归调下一片——容易栈溢出；用for await (const chunk of chunks)+await uploadOneChunk(chunk)更可控
最关键的细节往往藏在服务端：前端生成的 uploadId 必须全局唯一（推荐 crypto.randomUUID()），且服务端保存每个 chunkIndex 的元数据时，必须包含文件名、MD5、size 三重校验字段——否则合并时发现某片内容损坏，根本没法定位是哪次上传出的问题。
