file.slice()的start和end必须是字节偏移量，非mb字符串或字符数；正确写法为const chunk_size = 5 1024 1024，配合math.min(start + chunk_size, file.size)兜底，避免越界与损坏。
用 file.slice() 切片时，start 和 end 必须是字节偏移量
很多人写 file.slice(0, '5MB') 或 file.slice(0, 5000000)，结果上传后服务端校验失败、Content-Range 报错、文件损坏。因为 slice() 的参数单位永远是字节（byte），不是 MB 字符串，也不是字符数——UTF-8 中一个中文可能占 1–3 字节，slice(0, 100) 可能只切了几十个汉字。
正确做法是显式换算并兜底：
- 定义常量：
const CHUNK_SIZE = 5 * 1024 * 1024（5MB） - 每次计算：
const start = i * CHUNK_SIZE，const end = Math.min(start + CHUNK_SIZE, file.size) - 调用：
file.slice(start, end)—— 返回新Blob，不复制内存，开销极低
别硬编码 5242880 这类数字，可读性差且易错；也别依赖 file.name 或 file.lastModified 做分片标识，它们无法区分内容不同但同名的文件。
切片大小设多少？为什么不能直接 Promise.all 全部并发
单片建议 2–5 MB：2 * 1024 * 1024 到 5 * 1024 * 1024。太小（如 100KB）会显著增加 HTTP 请求头开销和 TCP 握手次数；太大（如 50MB）单片超时概率高，失败就得重传整块，反而拖慢整体进度。
并发必须限流，不能 Promise.all(chunks.map(upload)) 一把梭：
- 1GB 文件切 200 片，
Promise.all会瞬间发出 200 个请求，触发浏览器同域连接上限（Chrome 默认 6）、服务端限流拒绝、内存暴涨甚至页面冻结 - 稳定做法是控制“飞行中”请求数 ≤ 4，用
Promise.allSettled+ 队列推进，每次只提交最多 4 个分片 - 每个
fetch或XMLHttpRequest实例必须独立创建，上传完成立即释放引用（如设xhr = null）
切片上传必须带哪些关键字段？为什么不能只靠文件名判断断点
每个分片请求至少要附带：
-
uploadId：必须基于文件内容生成，推荐用crypto.subtle.digest('SHA-256', buffer)流式计算全文件哈希（或分片哈希聚合），存入sessionStorage；不能用file.name或Math.random()，否则同名文件、修改后重传会状态错乱 -
chunkIndex和totalChunks：服务端靠它排序、去重、幂等写入 -
Content-Range头：格式为bytes 0-5242879/1073741824，服务端据此定位写入位置；漏掉或格式错误会导致合并失败
服务端需返回已传分片索引列表（如 ["0", "2", "3"]），前端据此跳过，而不是靠“上次传到第几片”这种不可靠的本地计数。
切片读取时怎么避免卡死主线程
直接 FileReader.readAsArrayBuffer(file) 整体读大文件，页面会卡死，尤其在低配设备上。关键是把“切”和“读”解耦：
-
file.slice()本身不耗时，它只是生成视图引用；真正阻塞的是后续读取或上传 - 避免一次性生成全部分片 Blob；改用循环 +
await new Promise(r => setTimeout(r, 0))插入微任务间隙，让 UI 保持响应 - 读取每片时用
FileReader，读完立刻设reader = null释放引用，防止 GC 压力堆积 - 不要用
readAsDataURL或readAsText，它们会做额外编码转换；统一用readAsArrayBuffer获取原始二进制
真正难的不是“怎么切”，而是怎么让切、读、传这三步都轻量可控——尤其是 uploadId 的生成和持久化，一旦刷新就丢，断点续传就失效，这个细节最容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
